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ABSTRACT 

Automated  data  processing  for  non-tactical  applications  afloat  was  first  implemented 

on  large  platforms  with  the  SNAP  I  system.  This  system  provided  excellent  inventory 
management,  financial  and  accounting  service  in  the  punch  card  and  magnetic  tape 
environment  in  which  it  was  introduced.  Subsequent  modifications  have  been  made  to 
take  advantage  of  changing  technologies  and  increased  user  expectations. 

Automated  data  processing  on  smaller  platforms  was  implemented  with  the  SNAP 
II  program.  While  serving  many  of  the  same  functions  this  implementation  was  designed 
separately  and  for  a  different  user  group. 

The  SMMS  program  discussed  here  in  a  case  format  was  an  attempt  to  consolidate 
and  enhance  the  two  SNAP  programs. 
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I.    INTRODUCTION 

A.  THE  TOPIC 

This  thesis  will  point  up  some  of  the  many  and  often  conflicting 
influences  that  impact  on  management  information  system  and 
programming  decisions  in  the  naval  environment.  These  trends  and 
pressures  are  presented  in  a  case  study  setting  with  enough  background 
material  to  allow  the  reader  to  grasp  the  complexity  of  the  situation. 
Rather  than  espousing  one  right  answer  the  reader  should  come  away  with 
personal  solutions  that  will  aide  them  in  confronting  similar  projects. 

B.  BACKGROUND 

The  first  automated  non-tactical  systems  to  go  to  sea  were  designed  to 
provide  supply  and  financial  functions  for  auxiliary  ships.  These  systems 
kept  track  of  material  carried  on  board  but  belonging  to  an  ashore  activity. 
They  also  provided  record  keeping  for  the  ship's  own  financial  and  supply 
requirements.  This  first  system  was  called  SNAP  I  for  Shipboard  Non- 
tactical  Automated  Data  Processing.  The  system  ran  on  a  mainframe 
computer  in  batch  processing  mode.  The  initial  system  used  punch  cards 
and  reports  and  financial  data  tended  to  be  about  a  week  behind  the  actual 
transactions.  Subsequent  upgrades  in  hardware  and  software  have  moved 


some  ships  and  shore  stations  to  the  current  version  known  as  Shipboard 
Uniform  Automated  Data  Processing  System-Real  Time  (SUADPS  RTXPRC, 
1991)  or  SNAP  I  release  three.  The  real  time  in  the  name  implies  that  the 
processing  is  almost  instantaneous  after  the  transaction  is  input  to  the 
system.  Although  some  might  argue  that  the  system  only  simulates  a  real 
time  mode,  since  transactions  update  copies  of  data  files  on  a  real  time 
basis.  Actual  updates  of  the  master  financial  and  inventory  files  are 
modified  in  batch  updates  on  a  daily  basis.  This  situation  is  somewhat 
analogous  to  a  deposit  in  an  automatic  teller  machine  where  your  balance 
is  shown  with  the  deposit  added  but  a  lower  balance  will  be  shown  if  the 
machine  is  immediately  rechecked.  The  new  higher  balance  will  only  show 
again  after  the  deposit  envelope  has  been  opened  and  the  master  record 
updated. 

Subsequent  to  SNAP  I,  SNAP  II  was  designed  to  provide  the  financial 
and  inventory  record  keeping  portion  of  SNAP  I  that  applied  to  smaller 
ships  onboard  spares  inventory  and  consumable  items.  In  SNAP  I  the 
similar  section  was  called  own  ships  use.  SNAP  II  was  designed  for  ships 
using  micro  or  mini  computer  hardware,  afloat  accounting  and  far  fewer 
staff  people  to  run  it.  The  financial  section  of  the  small  ships  system  was 
simpler  since  these  ships  were  only  required  to  maintain  internal  budgets, 


operating  target  (OPTAR)  logs  and  end  use  stock  records;  and  did  not 
require  accounts  for  wholesale  and  retail  stocks  and  costs  for  tended  vessels. 
These  financial  record  systems  also  represent  simplified  afloat  accounting 
rather  than  the  more  complex  shore  station  system  used  in  SNAP  I.  This 
more  complex  shore  accounting  used  in  the  SNAP  I  systems  stems  from  the 
fact  that  the  majority  of  the  inventory  controlled  actually  belongs  to  the 
Navy  Stock  Fund  and  is  not  the  property  of  the  ship. 

The  two  SNAP  systems  perform  many  of  the  same  functions  with 
regard  to  internal  ships  supply  functions.  Despite  the  seeming  functional 
similarities,  each  system  was  developed  separately  for  different  hardware 
configurations.  Designing  to  these  hardware  differences  yielded  systems 
with  little  in  common  with  regard  to  how  they  "look  and  feel"  from  the 
human  interaction  standpoint.  For  example,  the  Storekeeper  (SK)  rating 
has  had  two  sets  of  questions  in  the  advancement  exams  representing  how 
functions  are  symbolized  and  performed  on  the  two  systems.  Of  concern 
from  a  manpower  assignment  perspective  is  that  a  junior  SK  is  much  more 
likely  to  have  hands-on  training  in  the  SNAP  II  system  but  he  or  she  is  apt 
to  be  subsequently  asked  to  supervise  on  a  SNAP  I  afloat  platform  or  shore 
activity  without  any  real  background.  This  requirement  for  two  separate 
training  pipelines  has  been  a  motivator  for  standardizing  as  many  functions 


as  possible  between  the  two  systems.  The  possible  cost  savings  from 
reducing  the  number  of  systems  being  maintained  is  also  a  motivator  in 
funding  constrained  environment  of  the  early  1990s. 

The  differences  between  the  two  SNAP  systems  are  reflected  in  the 
parallel  organizational  structures  maintained  to  supervise  them.  All 
surface  and  submarine  type  commanders  maintain  separate  internal 
organizations  to  provide  guidance  to  supervised  activities  using  each 
system.  The  experience  sought  in  staff  and  the  guidance  given  to 
subordinate  activities  varies  widely  between  SNAP  I  and  SNAP  II 
organizations. 


C.      SOURCES  OF  INFORMATION 

Due  to  the  lack  of  literature  in  the  area  of  SNAP  I  and  SNAP  II 
consolidation,  the  majority  of  sources  of  information  were  personal 
interviews  conducted  at  Navy  Management  System  Support  Office 
(NAVMASSO)  in  June  of  1991  and  follow-up  phone  calls  to  NAVMASSO 
and  Naval  Supply  Systems  Command  Fleet  Support  Division  (NAVSUP 
04D).  Further  input  was  obtained  from  vendor  product  documentation, 
articles  in  current  computer  periodicals,  Navy  notices  and  instruction  and 


survey  data  collected  from  Type  Commanders  in  the  Atlantic  and  Pacific 
fleets  and  the  Marine  Corps  by  NAVSUP  in  the  fall  of  1991. 


II.  CASE  METHODOLOGY 

A.  CASE  STUDY  FOR  RESEARCH 

A  case  study  "investigates  a  contemporary  phenomenon  within  its  real 
life  context;  when  the  boundaries  between  phenomenon  and  context  are  not 
clearly  evident;  and  multiple  sources  of  evidence  are  used. "(Yin,  1989) 

The  appropriate  subject  matter  for  a  good  case  may  be  a  cutting  edge 
problem  not  yet  faced  by  many  business  leaders.  Most  cases  should  center 
on  common-place  problems  routinely  faced  by  managers.  (Culliton,  n.d.) 

A  case  study  attempts  to  capture  a  snapshot  of  an  organizational 
situation  as  it  unfolds,  without  imposing  experimental  controls.  In  a  case, 
an  observer  attempts  to  see  the  invisible  forces  acting  in  and  on  an 
organization  through  the  observable  actions  of  individuals.  (Lee,  1986) 

B.  TYPES  OF  CASES 

Culliton  (1973)  groups  cases  into  three  general  types  based  on  the 
degree  of  problem  specificity.  The  first  and  generally  the  shortest  is  the 
specific  problem  case.  These  cases  are  quite  specific  about  the  nature  of  the 
problem  and  who  has  the  problem.  The  second,  longer  type  is  the 
diagnostic  case.  In  these  cases  fact  that  someone  has  a  problem  is  less  clear 
cut.    The  specifying  of  the  problem  and  the  person  or  persons  having  the 


problem  is  more  open  to  interpretation  than  in  the  specific  problem  case. 
The  third  type  and  usually  longest  is  the  appraisal  case.  In  this  type 
readers  may  clearly  disagree  on  whether  there  is  a  problem  or  not.  The 
topic  of  discussion  will  include  the  alternative  of  not  changing  anything. 
"Prognosis  may  be  more  important  than  diagnosis." 

Bennett(Davis  ,n.d.)  takes  a  somewhat  more  restrictive  view  on  types 
of  cases.  His  two  categories  of  cases  are  both  closely  related  to  the  specific 
problem  case.  The  first  type  is  the  issue  case  in  which  the  author  presents 
a  problem  and  the  reader  develops  scenarios  to  solve  it.  The  second  type  is 
the  appraisal  case  where  the  author  describes  a  management  solution  used 
and  the  reader  critics  the  solution. 

Both  authors  agree  that  the  time  span  of  a  case  is  specific.  The  span 
covered  should  be  decided  and  events  happening  after  the  period  covered 
should  be  excluded.  Only  in  such  a  limitation  can  a  realistic  problem 
solving  situation  be  created. 

C.     ADVANTAGES  OF  TEACHING  CASES 

Proponents  of  the  case  study  method  of  teaching  feel  that  the  quality 
and  quantity  of  material  retained  by  the  student  is  larger  when  the  case 
method  is  used.     The  advantages  are  attributed  to  information  fallout 


phenomena.  The  fallout  results  from  the  students  seeing  an  immediate 
application  of  and  use  for  the  information  received. (Culliton,  1973) 

The  use  of  qualitative  data  and  descriptions  can  be  an  advantage  in 
the  case  study  method.  Descriptions  of  situations  and  context  can  give  the 
reader  a  greater  perception  of  the  nature  of  real  life  decision  making.  Such 
rich  descriptions  can  stir  the  readers  imagination  more  readily  than  bare 
numerical  data. (Miles,  1984) 

A  case  study  method  teaches  the  student  that  there  is  often  more  than 
one  viable  alternative.CPascale,  1973)  The  habits  of  diagnosing  problems, 
analyzing  and  evaluating  alternatives  and  developing  possible  responses 
have  value  in  their  own  right. (Harvey,  1988)  The  case  method  can  also 
illustrate  the  influence  of  political  power  on  decision  making. (Lee,  1986) 

Skills  learned  in  dealing  with  the  case  methodology  can  be  particularly 
valuable  in  the  information  systems  arena.  The  rapid  rate  of  technological 
change  and  innovation  in  the  information  system  area  have  a  continuing 
impact  on  organization  and  management.  The  deductive  skill  and  insights 
gained  through  the  use  of  cases  can  provide  excellent  preparation  for 
change.(Benbasat,  1987) 
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D.     DISADVANTAGES  OF  CASE  STUDIES 

The  use  of  qualitative  data  can  be  a  disadvantage  of  case  studies 
particularly  when  they  are  used  for  research.  Qualitative  data  in  case 
studies  tends  to  be  very  difficult  for  a  follow  on  researcher  to  duplicate  and 
thus  verify.(Lee,  1986)  Standardized  methods  of  analysis  for  qualitative 
data  are  lacking.CMiles,  1984) 

Data  collection  methods  for  case  studies  can  be  time-consuming  and 
require  extensive  documentation.  Even  if  abbreviated  methods  of  data 
collection  are  use,  production  of  a  quality  case  study  is  a  difficult  endeavor. 
No  proven  criteria  have  been  developed  to  determine  if  an  author  has  the 
requisite  skills  to  write  a  quality  case  study.  Yet  critics  argue  that  results 
obtained  can  only  be  generalized  with  extreme  care. (Yin,  1989) 


III.   NON-TACTICAL  ADP  ENVIRONMENT 

A.     INTRODUCTION 

Traditionally  the  Navy  has  separated  the  automated  data  processing 
(ADP)  function  into  two  categories,  tactical  and  non-tactical.  The  Warner 
amendment  to  the  Brooks  act  and  the  paperwork  reduction  reauthorization 
act  of  1986  both  drew  a  distinction  in  the  equipment  covered  by  the  law 
based  on  application  within  the  Department  of  Defense. (McDonough,  1990) 
Generally  ADP  applications  that  were  of  a  tactical  nature  or  part  of  a 
weapon  system  were  exempted  and  thus  subject  to  fewer  regulatory 
guidelines.  On  the  non-tactical  side,  programs  and  applications  are  subject 
to  a  different  set  of  standards  and  require  more  extensive  justification  along 
cost  benefit  lines. 

The  net  effect  of  the  traditional  separation  was  to  have  distinct 
hardware  and  software  developments  in  the  two  areas.  The  people  who 
developed  the  two  types  of  systems  worked  at  different  activities  and 
seemed  to  have  little  in  common.  These  separations  were  heightened  by  the 
fact  that  tactical  systems  tended  to  be  organic  to  pieces  of  hardware  and  to 
be  either  real  time  or  interactive  in  nature.  Non-tactical  systems  on  the 
other  hand  originally  tended  to  be  based  on  large  mainframe  operations  and 
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were  batch  in  nature  or  else  they  were  stand  alone  and  used  largely  for 
word  processing. 

B.     ADP  DISTINCTIONS  DIMINISHING 

In  a  speech  to  the  September  1991  Navy  micro  computer  conference, 
the  Navy's  senior  ERM  official,  Gerald  Cann,  addressed  current  trends  in 
Navy  ADP. (Green,  1991)  He  feels  that  the  old  differences  between  tactical 
and  non-tactical  hardware  and  software  are  diminishing.  In  parallel  with 
this  trend,  the  separation  in  the  procurement  methods  used  is  also 
decreasing. 

Custom  made  software  for  use  with  tactical  systems  is  being 
supplanted  by  off-the-shelf  packages.  This  trend  should  allow  the 
procurement  system  to  reduce  or  eliminate  the  distinctions  which  have 
confused  procurement  issues  dealing  with  tactical  and  non-tactical 
technology.  Cann  also  strongly  believes  that  the  acquisition  cycle  for 
computers  should  be  reduced  to  an  18  month  turn  around. (Green,  1991) 

Robert  Green,  director  of  information  resources  interoperability  for  the 
Navy's  Information  Technology  Acquisition  Center  gives  further  insight  into 
the  changes  taking  place.  In  1991,  the  data  processing  systems  in  ships 
tend  to  support  the  separate  activities  and  the  groups  supporting  those 
activities. (Robb,  1991)  If  a  part  fails  in  a  tactical  system  the  request  for  a 
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spare  part  would  first  go  to  the  division  maintenance  people  for  a  check  of 
the  ready  service  spares  bins.  If  it  is  not  found  the  search  would  be 
extended  to  supply  department  stocks.  The  request  would  have  to  be 
entered  into  a  separate  supply  system.  Even  if  the  part  is  found  onboard, 
the  maintenance  action  performed  must  be  entered  into  a  separate 
maintenance  tracking  system.  If  the  part  is  not  found  and  the  equipment 
is  non-functional,  a  casualty  reporting  system  will  become  involved.  Mr 
Green  sees  an  integrated  environment  coming  where  the  failure  of  the  part 
and  the  required  responses  can  be  largely  automated  without  repeated 
intervention  in  the  form  of  duplicate  data  entry  into  parallel  systems. (Robb, 
1991) 

The  integration  of  tactical  and  non-tactical  networks  is  demanding  a 
new  level  of  cooperation  from  two  systems  commands,  NAVSEA  (Naval  Sea 
Systems  Command)  and  SPAWAR  (Space  and  Naval  Warfare  Systems 
Command).  NAVSEA  previously  dealt  mainly  with  problems  internal  to  the 
ship  while  SPAWAR's  main  emphasis  was  on  problems  external  to  the 
ship.(Robb,  1991) 

Yet  another  perspective  can  be  gained  by  looking  at  the  changes  taking 
place  in  the  way  the  Navy  buys  ADP  equipment.  Captain  McQueen, 
commanding  officer  of  Information  Technology  Acquisition  Center  (ITAC) 
recently  gave  his  perspective.(Robb,  1991)  The  trend  in  industry  is  to  lower 
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the  barriers  between  telecommunications  and  computers.  It  would  be 
difficult  to  say  whether  the  move  toward  the  picture  phone  and  other 
broadband  communications  or  the  trend  toward  multimedia  and  distributed 
computing  is  the  main  driver  but  distinctions  are  blurring.  ITAC  will  be 
buying  both  base  telecommunications  systems  and  information  processing 
systems.(Robb,  1991) 

The  ITAC  staff  will  be  buying  the  $40  million  Tactical  Advanced 
Computer  (TAC-3)  procurement  as  well  as  the  SNAP-3  procurement,  now 
in  its  early  planning  stages(Robb,  1991). 

C.     PROGRAMMING  LANGUAGES 

In  1987  the  Defense  Department  issued  a  Directive  replacing  its 
earlier  1976  Instruction  on  Higher  Order  Languages  (HOD  in  the 
Department  of  Defense.  The  directive  provides  policy  guideline  for 
computer  programming  languages  used  in  both  development  and  support 
of  DoD  software(DoD  3405.1,  1987). 

As  in  personal  computers  and  other  non-government  business 
applications  there  is  a  tradeoff  between  changing  to  the  latest  tool  and  the 
large  capital  investment  in  an  already  acquired  inventory  of  software.  The 
directive  attempts  to  balance  these  opposing  forces  while  limiting  the 
overall  number  of  HOLs  that  are  allowed.  The  main  thrust  of  the  limitation 
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is  to  support  the  goal  of  transition  to  the  use  of  Ada(MIL-STD-1815A,  1983) 
for  Department  of  Defense  software  development DoD  3405.1,  1987). 

In  support  of  the  transition  goal  a  list  of  the  only  acceptable  HOLs  is 
included.  These  authorized  HOLs  can  be  used  to  complete  major  projects 
that  have  passed  milestone  IKDoD  5000.1,  1986).  In  these  and  other 
completed  projects  the  other  languages  can  be  used  subsequently  for 
software  maintenance  but  not  for  major  upgrades.  Other  authorized  HOLs 
may  also  be  authorized  for  projects  where  they  have  a  demonstrable 
advantage  over  AdaCDoD  3405.1,  1987).  This  advantage  should  be  in  terms 
of  life-cycle  cost  savings  and  fulfillment  of  system  requirements. 

The  Directive  states  preference  can  be  given  to  off-the-shelf  software 
and  advanced  software  technology.  However,  due  consideration  must  have 
been  given  to  the  future  impact  on  competition  for  software  and 
hardware(DoD  3405.1,  1987).  Use  of  the  new  technology  must  not  set  up 
future  sole  source  buy  situations  unfavorable  to  the  government. 

More  recent  events  seem  to  reinforce  the  stand  taken  by  DoD  on  Ada. 
In  1991  Paul  Strassmann,  director  of  defense  information,  asked  the  DOD's 
Information  Technology  Policy  Board  to  evaluate  Ada  and  C++  which  is  not 
on  the  list  of  approved  HOLs(DoD  3405.1,1987)  and  recommend  whether 
DOD  should  use  C++  for  some  projects.  Five  contractors  prepared  reports 
with  their  efforts  coordinated  by  Lloyd  K.  Mosemann,  deputy  assistant 
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secretary  of  the  Air  Force  for  communications,  computers  and 
logistics( Schwartz,  1991).  No  significant  reasons  were  found  to  "waive  the 
Ada  requirement"  in  favor  of  C++(Schwartz,  1991).  One  of  the  reporting 
contractors  TRW  Inc.  found  Ada's  score  on  a  range  of  software  engineering 
issues  to  be  over  20%  higher  than  the  score  tabulated  for  C++.  This  same 
report  recommended  that  waivers  for  the  use  of  C++  at  least  through  1993 
only  be  granted  for  conversion  of  software  originally  written  in  C(Schwartz, 
1991). 

D.     TRENDS 

The  overall  trend  in  shipboard  computing  is  toward  consolidation  of 
systems.  The  smaller  number  of  hardware  and  software  systems  that  need 
to  be  supported  allows  economies  in  staffing,  lower  software  maintenance 
costs,  and  fewer  repair  part  requirements. 

DoD  is  attempting  to  consolidate  and  standardize  programming 
languages.  Streamlining  the  programming  of  new  systems  by  reuse  of 
previously  developed  code  should  save  money.  Ada  was  developed  with 
reuse  of  code  segments  as  a  basic  premise.  The  use  of  Ada  is  now  being 
expanded  from  tactical  applications  into  all  shipboard  applications. 
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IV.   SNAP  CONFIGURATION  MANAGEMENT 

A.  OBJECTIVES 

The  stated  objectives  of  SNAP  configuration  management  were: 

a.  To  assist  SNAP  program  management  in  achieving  the  most  cost- 
effective  performance,  operational  efficiency,  implementation  schedule, 
logistic  support  and  readiness. 

b.  To  attain  maximum  efficiency  in  the  management  of  engineering 
changes. 

c.  To  achieve  the  following  goals  at  a  system  level: 

(1)  To  ensure  that  verified  configuration  technical 
documentation  is  available  when  needed. 

(2)  To  maintain  hardware  and  software  standardization  and 
compatibility. 

(3)  To  ensure  that  total  performance,  costs,  and  schedule  impact 
of  change  proposals,  deviations,  and  waivers  are  known  at  the  time  of 
approval. 

(4)  To  ensure  that  all  hardware  and  software  configurations  are 
defined  and  that  pertinent  physical  and  functional  interfaces  between 
systems,  equipments,  and  software  programs  are  documented  and 
controlled.(SPAWAR  4130.12,  1986) 

B.  ORGANIZATION 

The  same  instruction  established  a  system  of  boards  and  committees 
to  carry  out  these  stated  objectives(SPAWAK  4130.12,  1986).  The  SNAP 
Joint  Configuration  Control  Boards  ( JCCBs)  were  chaired  by  the  SPA  WAR 
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SNAP  Program  Directorate  or  designee,  who  had  ultimate  authority  for  it's 
decisions.  The  JCCBs  also  have  permanent  members  representing  the 
Commander  NAVSEASYSCOM  and  Commanding  Officer  Navy 
Management  System  Support  Office  (NAVMASSO).  The  SNAP  I JCCB  had 
additional  permanent  members  representing  Commander,  Naval  Air 
Systems  Command  (NAVAIR)  to  interface  on  matters  relating  to  Naval  Air 
Logistics  Command  Management  Information  System  (NALCOMIS), 
Commander,  Naval  Data  Automation  Command  (NAVDAC)  for  Type 
Commander  Headquarters  Automated  Information  System  (THAIS) 
matters,  and  a  non-voting  member  from  the  Automated  Data  Processing 
Selection  Office  (ADPSO)  to  advise  on  SNAP  I  contract  matters.  The 
JCCBs  further  had  Ad  Hoc  members  representing  SNAP  Functional 
Managers,  Chief  of  Naval  Education  and  Training  (CNET),  and  the  Fleet 
Commanders  in  Chief.  The  SNAP  I  JCCB  also  had  an  Ad  Hoc  member 
representing  the  Commandant,  Marine  Corps. 

Subordinate  to  the  JCCB  were  the  SNAP  Hardware  Configuration 
Control  Committees  (HCCCs).  The  Chairman  of  these  committees  and  final 
arbiter  on  any  matters  not  requiring  referral  to  the  JCCBs  was  Commander 
NAVSEASYSCOM  or  his  designee.  SPAWAR  as  the  SNAP  program 
manager  was  a  permanent  member  of  the  HCCCs  and  had  the  authority  to 
refer  proposals  to  the  JCCBs  for  decision.  The  other  permanent  members 
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were  representatives  of:  NAVMASSO  fleet  Central  Design  Agency  and 
Naval  Sea  Combat  Systems  Engineering  Station 
(NAVSEACOMBATSYSENGSTA)  as  In  Service  Engineering  Activity 
(ISEA).  The  SNAP  I  HCCC  also  had  permanent  members  representing 
NAVAIR  the  NALCOMIS  Program  Manager  and  a  non- voting 
representative  of  ADPSO  to  answer  questions  on  the  AN/UYK-65  hardware 
contract.  The  Ad  Hoc  members  of  the  HCCCs  were  representatives  of  at 
least  the  following:  Naval  Supply  Systems  Command  (NAVSUP)  to  insure 
proper  coordination  with  its  inventory  control  points,  CNET  as  SNAP 
training  interface  and  Fleet  Commanders  in  Chief  as  user  representatives. 
SNAP  I  HCCC  also  had  Ad  Hoc  members  representing  the  Commandant, 
Marine  Corps  as  a  user  and  NAVDAC  for  THAIS  interface. 

Also  subordinate  to  the  JCCBs  were  the  SNAP  Software  Configuration 
Control  Committees  (SCCCs).  The  Chairman  of  these  committees  and  final 
arbiter  on  any  matters  not  requiring  referral  to  the  JCCBs  was 
Commanding  Officer  Navy  Management  Support  Office  (NAVMASSO)  or 
his  designee.  SPA  WAR  as  the  SNAP  program  manager  was  a  permanent 
member  of  the  SCCCs  and  again  had  authority  to  refer  proposals  to  the 
JCCBs  for  decision.  In  a  swapping  of  roles  from  the  HCCCs  another 
permanent  member  was  a  representative  of  NAVSEA  to  evaluate  the 
potential      impacts      of     changes      on      hardware      and      firmware. 
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NAVSEACOMBATSYSENGSTA  as  ISEA  was  again  a  permanent  member. 
The  SNAP  I SCCC  also  had  permanent  members  representing  NAVAIR  the 
NALCOMIS  Program  Manager,  Navy  Regional  Data  Automation  Center 
Norfolk  representing  THAIS  issues  and  a  non-voting  representative  of 
ADPSO  to  answer  questions  on  SNAP  I  contract  issues.  The  Ad  Hoc 
members  of  the  SCCCs  were  representatives  of  at  least  the  following: 
Commander  Naval  Supply  Systems  Command  (COMNAVSUPSYSCOM)  as 
SNAP  Functional  Manager,  CNET  as  SNAP  training  interface  and  Fleet 
Commanders  in  Chief  as  user  representatives.  SNAP  I  SCCC  also  had  Ad 
Hoc  members  representing  the  Commandant,  Marine  Corps  as  a  user. 

C.     RESPONSIBILITIES 

The  JCCBs  were  responsible  for  overall  policy  guidance  on 
prioritization  of  change  actions,  reporting  requirements,  and  general 
management  of  the  program.  They  were  also  responsible  for  announcing 
their  meetings  at  least  45  days  in  advance  to  allow  the  subordinate 
committees  to  publish  and  distribute  agenda  items  30  days  before  the 
meetings.  Issues  requiring  new  funding,  schedule  changes  or  not  limited 
to  Hardware  or  Software  areas  as  well  as  after  the  fact  reviews  of  the 
decisions  of  the  SCCCs  and  the  HCCCs  also  were  the  JCCBs  responsibility. 
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The  HCCCs  were  responsible  for  hardware  and  firmware  configuration 
control,  record  keeping,  auditing  of  installations  and  monitoring  of 
contractor  configuration  management.  They  also  had  to  evaluate  integrated 
logistics  support  elements  and  funding  levels  before  implementing 
configuration  changes.  Finally  they  had  to  organize  and  research  and 
provide  recommendations  for  issues  that  were  to  be  referred  to  the  JCCBs 
for  resolution. 

The  SCCCs'  responsibilities  included  deciding  all  software  change 
issues  that  don't  effect  funding  levels,  scheduling  or  hardware.  They  also 
develop  procedures,  conduct  audits,  perform  configuration  status  accounting 
and  historical  record  keeping.  Finally  they  develop  schedules  and  priorities 
for  their  area  of  responsibility. 
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V.   SNAP  MATERIAL  MANAGEMENT  SYSTEM  CASE  STUDY 

A.     CASE  SITUATION1 

In  August  1989  SMMS  project  manager  Margaret  Winston  at 
NAVMASSO  in  Norfolk  Virginia  assigned  Bobby  Jenkins  and  three  other 
analysts  to  start  data  modeling  and  analysis  of  the  SNAP  Material 
Management  System  (SMMS)  project.  This  initial  effort  was  centered 
around  the  Information  Engineering  Systems  Corporation  (IESC) 
methodology  and  was  assisted  by  one  of  a  series  of  rotating  contractor 
personnel. 

In  keeping  with  the  IESC  format,  emphasis  was  placed  on  data  not 
procedures  and  business  knowledge  rather  than  technology.  The  IESC 
CASE  tool  focuses  on  modeling  the  business  process  using 
Finkelstein's(Keyes,  1992)  method  of  breaking  activities  down  into  fourth 
and  fifth  business  normal  form.  The  data  is  divided  and  then  grouped  into 
entities  which  represent  a  table  in  a  relational  data  base  in  fifth  normal 
form.  All  possible  relations  between  data  elements  are  defined  in  one  of 
these  tables.     This  separation  of  data  into  fifth  normal  form  permits  a 


^his  is  a  preliminary  version  of  a  case  study  which  has  not  yet 
been  approved  for  public  release.  It  is  not  for  republication  or 
quotation. 
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segregation  of  business  detail  into  objects.  These  objects  are  intended  to 
group  data  and  the  associated  relationships  and  interactions  between 
data(Keyes,  1992).  In  support  of  this  task  the  IESC  CASE  tool  generates 
numerous  reports  including  Entity  Report,  Entity  Purpose  Report, 
Association  Report,  Subject  data  base  implementation  priorities,  and 
Attribute  Report. 

Over  the  ten  months  of  the  modeling  effort,  Margaret's  group  defined 
and  categorized  increasingly  complex  entity  models  until  three  hundred  and 
fifty  eight  active  entities  had  been  defined.  The  condensed  version  of  the 
first  four  reports  showing  only  active  entities  had  grown  to  one  hundred  and 
seventy  pages  by  mid  1991. 

In  the  twelve  months  of  the  IESC  contract,  twelve  different  consultants 
were  assigned.  One  of  the  first  IESC  consultants  with  some  non-specified 
informal  input  from  senior  officers  in  the  Washington  arena,  initially 
identified  the  following  twenty  five  business  functional  areas. 

•  Transaction  Access 

•  Organization  Identification 

•  Organization  Categorization 

•  Address 

•  Person 

•  Skill 
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Item  Identification 
Contract 
Customer  Need 
Performance  Monitoring 
Priority  Management 
Requisition  Status 
Supply  Requirement 
Supply  Requisition 
Item  Handling 
Location 

Requisition  Receipt 
Item  Configuration 
Organization  Allowance  Level 
Organization  Item  Management 
Inventory  Physical  Distribution 
Item  Management 
Fund  Accounting 
Fund  Authorization 
Fleet  Freight  (NAVMASSO,  1991) 
At  a  more  tactical  level  the  business  functional  areas  were  grouped 
into  four  functional  areas  and  assigned  to  the  four  analysts  at  NAVMASSO 
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for  development  of  entities  within  areas.  Financial  was  first,  consolidating 
accounting  practices  under  ashore  and  afloat  rules.  Second  were  security 
concerns.  Requirements  and  inventory  control  were  third  and  fourth 
respectively.  Next,  end  user  input  was  solicited  from  seven  commands, 
each  one  level  above  actual  operational  units.  Each  of  these  commanders 
controlled  operational  units  using  either  SNAP  I  or  SNAP  II.  Group 
meetings  were  scheduled  and  held  on  both  coasts  to  identify  the  basic 
entities  which  in  the  IESC  scheme  would  be  the  low  level  objects  and  the 
logic  that  acts  on  those  objects.  In  addition  to  basic  entities,  the  meetings 
were  to  develop  attributes  and  relationships  of  entities  as  well  as  edit  rules 
and  display  input  items.  Between  meetings,  the  NAVMASSO  analysts  and 
IESC  consultant  used  the  IESC  computer  aided  software  engineering  tool 
to  model  the  data  for  review  at  the  next  meeting. 

By  the  end  of  the  second  cycle  of  meetings  Bobby  and  the  other 
NAVMASSO  analysts  had  noticed  some  general  differences  in  viewpoint  in 
representatives  of  Atlantic  and  Pacific  fleets.  The  Atlantic  fleet 
representatives  seemed  to  expect  a  greater  amount  of  top-down  supervision 
and  less  flexibility  in  the  system  at  the  operational  level.  They  also 
expected  reports  to  higher  authority  to  contain  more  detail.  Finally,  the 
East  coast  representatives  modeled  a  system  where  more  help  was  extended 
down  the  chain  in  terms  of  outside  organizations  providing  supplemental 
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parts  tracking  services  and  similar  functions.  The  analysts  also  noticed 
that  representatives  of  the  submarine  community  saw  the  testing  records 
and  certification  of  nuclear  related  parts  as  a  top  concern  while  aviators 
seemed  more  concerned  with  tracking  the  return  of  equipments  for  repair. 

Successive  meetings  of  the  user  groups  encountered  weeks  of  delays 
due  to  varying  opinions  expressed  by  senior  storekeepers  and  supply  officer 
representatives  from  various  commands  and  from  representatives  of  the 
same  commands  at  successive  meetings.  More  than  once,  these 
disagreements  as  to  the  nature  of  basic  entities  to  be  modeled  negated  the 
majority  of  the  work  accomplished  at  a  preceding  meeting.  Disagreements 
among  participants  were  intensified  by  the  fact  that  the  meetings  tended 
to  alternate  between  coasts  with  Atlantic  fleet  participants  attending  east 
coast  meetings  and  Pacific  fleet  representatives  attending  west  coast 
meetings.  Since  the  Atlantic  and  Pacific  fleets  have  their  own  sets  of 
instructions  and  reporting  requirements  dealing  with  shipboard  supply 
procedures,  groups  from  these  two  fleets  tended  to  have  differing  views  on 
which  reports  were  required  and  what  procedures  were  critical  and  which 
superfluous.  Even  more  frustrating  to  the  analysts  was  the  fact  that  even 
on  the  same  coast  the  changing  representatives  from  a  command  would 
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often  vary  in  their  views  from  meeting  to  meeting  thus  causing 
backtracking  and  reexamination  of  completed  areas. 

Despite  these  formidable  obstacles  to  progress,  the  analysts  were  able 
to  develop  cohesive  groups  of  entities  in  three  out  of  four  functional  areas 
by  the  fall  of  1990.  Financial  was  the  functional  area  not  completed, 
possibly  due  to  an  inability  to  resolve  the  differences  between  afloat  and 
ashore  accounting  practices.  With  this  exception,  the  analysts  believed  they 
were  ready  to  evaluate  the  SMMS  model  as  a  whole  with  the  end  users. 
Unfortunately  Operation  Desert  Storm  work  requirements  had  almost 
totally  depleted  the  pool  of  users  who  would  otherwise  do  the  evaluation 
and  the  project  went  into  a  holding  pattern. 

During  the  delay,  the  fact  that  the  computer  aided  software 
engineering  tool  in  use  was  centered  mainly  on  data  modeling  and  did  not 
provide  support  for  code  generation  was  reevaluated  by  the  project  steering 
committee.  In  order  to  take  advantage  of  potential  cost  savings  in  code 
generation  and  software  maintenance  costs,  CASE  tools  with  code 
generation  capability  were  considered.  Despite  the  fact  that  translation  of 
the  work  done  to  date  was  not  guaranteed  by  the  company,  the  decision  was 
approved  by  Admiral  Moore's  committee  to  use  a  new  CASE  tool  for  the 
remainder  of  the  project.  IESC  who  had  been  in  on  the  data  modeling  work 
was  discharged  but  four  copies  of  their  software  were  purchased  with  the 
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idea  that  in-house  staff  could  maintain  the  data  model  already  developed 
and  to  aide  in  translation  to  the  new  model.  As  late  as  June  1991  only  one 
copy  of  the  software  had  actually  been  loaded  and  had  proved  of  limited 
utility  in  the  transition  process. 

Three  new  integrated  CASE  tools  produced  by  Oracle  were  chosen. 
Oracle's  tools  define  business  applications  instead  of  business  functional 
areas  as  a  starting  point.  The  twenty  five  business  functional  areas  were 
grouped  into  nine  business  applications.  The  first  three  of  nine  applications 
to  be  defined  and  the  first  to  be  worked  were  material  id,  organization, 
material  procurement.  Translation  of  work  completed  using  the  IESC 
CASE  tool  to  the  new  Oracle  CASE  tool  has  proven  difficult  at  best. 

In  order  to  more  clearly  define  fleet  requirements  Admiral  Moore 
directed  COMNAVSUPSYSCOM  to  survey  the  fleet  user.  Due  to  an 
imminent  transfer  by  the  Captain  in  charge  of  sending  the  survey,  an 
extensive  four-part  and  200  page  questionnaire  was  hastily  sent  out  to  all 
the  users  and  subsequently  reduced  in  scope  to  type  commanders  only.  The 
loose  organization  and  redundant  nature  of  the  questions  in  the  survey  as 
well  as  the  length  impair  its  usefulness.  The  initial  impact  was  to  delay 
any  further  user  input  meetings  by  two  to  six  months  pending  return  and 
evaluation  of  survey  results. 
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B.     OTHER  CONSIDERATIONS 

The  Oracle  CASE  tool  generates  code  in  a  proprietary  language  SQL 
Forms  rather  than  Ada.  While  exceptions  to  the  use  of  Ada  as  a 
programming  language  in  DOD  could  be  obtained,  there  had  been  no 
commitment  to  use  SQL  Forms  for  other  non-tactical  shipboard 
applications.  SQL  Forms  was  also  not  listed  as  one  of  the  higher  level 
languages  approved  for  use  by  the  Department  of  Defense(DoD  3405.1, 
1987).  Use  of  a  non-standard  language  may  impede  future  communications 
between  and  integration  of  shipboard  systems. 

A  separate  group  of  analysts  at  NAVMASSO  was  working  on  a  project 
to  reverse  engineer  half  a  dozen  automated  shipboard  and  shore 
maintenance  tracking  programs.  These  programs  have  been  developed  by 
type  commanders  and  program  managers  to  track  maintenance  actions  on 
different  pieces  or  types  of  shipboard  equipment.  At  least  one  system 
developed  for  NAVSEA,  the  maintenance  resource  management  system 
(MRMS),  has  two  versions  one  for  SNAP  I  sites  and  one  for  non-SNAP  I 
sites(PRC,  1991).  Integration  of  these  programs  with  other  shipboard 
software  has  not  been  a  firm  requirement.  This  lack  of  interoperability  may 
be  due  to  the  lack  of  emphasis  and  non-availability  of  technology  at  the 
time  when  the  programs  were  developed.  The  analysts  are  attempting  to 
extract   and   preserve    the    best    parts    of  each    separate    system    in    a 
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standardized  system.  Even  though  this  system  will  need  to  communicate 
in  some  fashion  with  the  supply  software  no  commitment  had  yet  been 
made  to  any  data  model  or  specific  software. 

There  also  non-funded  long  term  goals  of  eventually  including  other 
supply  areas  as  well  as  shipboard  administrative  functions  in  a  centralized 
ships  data  baseCWinston,  1991).  While  these  considerations  have  not  yet 
received  the  credibility  of  being  funded  their  importance  may  increase  with 
the  continued  shift  toward  minimum  manning  and  maximum  efficiency  of 
shipboard  activities  and  equipment. 

In  June  1991,  no  consideration  had  been  given  to  a  direct  linking  of  the 
computerized  data  in  the  ship's  co-ordinated  shipboard  allowance  list  with 
the  supply  module.  Such  a  link  might  help  insure  that  the  system  reflected 
the  latest  in  ships  on  board  equipment  and  likewise  was  not  ordering  parts 
for  equipment  that  had  been  removed  in  overhauls. 

The  Oracle  vendor  estimated  that  the  run  time  modules  needed  to  run 
their  proprietary  software  on  local  area  networks  (LANs)  on  ships  would 
run  about  $150  per  copy(Oracle,  1991).  The  SQL  Forms  language  had  no 
capability  to  communicate  with  CD  ROM  based  technology  for  updating  of 
price,  stock  number  or  other  data.  Due  to  the  decreasing  cost  and  highly 
portable  nature  of  CD  ROM  technology,  this  lack  of  compatibility  may  limit 
future  expansion. 
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Currently,  none  of  the  Navy's  ashore  accounting  systems  have  been 
certified  by  the  GAO  mainly  due  to  the  lack  of  depreciation 
capability(Eberling,  1991).  The  data  requirements  of  such  a  new  system 
were  not  known  in  1991.  This  lack  of  guidance  could  be  a  major  challenge 
to  progress  on  the  financial  aspects  of  SMMS. 

SNAP  I  release  3  (realtime)  which  had  a  very  rocky  start,  with 
problems  encountered  in  its  processing  of  data  and  giving  immediate  or 
realtime  updates  to  data.  However,  release  3  is  starting  to  gain  more 
acceptance  by  the  pertinent  divisions  of  the  user  group  commands(Paite, 
1991).  Especially  when  compared  to  the  work  involved  and  risks  inherent 
with  building  and  installing  a  totally  updated  system.  Most  of  the  users 
have  been  involved  in  at  least  one  update  or  system  implementation  and 
know  that  every  time  a  major  change  is  made  to  a  system  there  are 
undetected  software  problems  that  must  be  fixed  retroactively.  In  an 
operational  environment  such  problems  with  supply  software  would 
interfere  with  the  units  ability  to  fix  broken  equipment  and  reduce  the 
supply  systems  credibility.  In  a  worst  case,  the  fix  may  take  long  enough 
to  put  the  whole  ship  at  risk. 

At  least  one  user  command  is  advocating  the  total  reappraisal  of  what 
functions  need  to  remain  afloat  and  what  ones  can  be  brought  ashore 
through  a  transaction  item  reporting  system(Smith,  1991).    Under  this 
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concept,  most  accounting  functions  would  be  moved  ashore.  In  the  shore 
environment,  tasks  could  be  civilianized  and  performed  by  civil  service 
employees  trained  in  accounting.  Even  if  the  jobs  were  still  done  by 
military  personnel,  they  could  be  specifically  trained  and  have 
knowledgeable  coworkers  and  a  telephone  consistently  available. 
Transactions  would  be  reported  via  electronic  means  on  satellite  links.  If 
such  a  change  were  to  be  implemented  it  would  require  basic  changes  in  the 
design  of  the  SMMS  system. 

C.     VIEW  FROM  THE  STEERING  COMMITTEE 

The  shipboard  arena  is  one  of  the  few  Navy  data  processing  areas  that 
remains  under  direct  Navy  control.  Keeping  those  shipboard  systems  viable 
and  maintainable  in  a  rapidly  changing  technological  and  fiscal 
environment  is  the  challenge.  Any  move  that  appears  to  be  wasteful  or 
smacks  of  adding  unnecessary  nice  to  have  items  is  sure  to  bring 
Congressional  criticism  and  possible  funding  cuts.  The  Navy  is  operating 
in  an  environment  where  not  even  the  number  of  type  commanders  is 
guarantied  to  remain  constant  but  decisions  must  be  made  on  continuing 
implementation  of  the  current  two  SNAP  systems  as  well  as  the  pace  and 
upgrading  within  those  systems.  Potential  end  users  vary  from  an  aircraft 
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carrier  with  a  LAN  consisting  of  over  200  units  to  small  ships  with  stand 
alone  PCs. 

D.     YOUR  CHARTER 

To  prepare  for  the  class  discussion,  adopt  the  perspective  of  the  head 
of  the  Navy's  ADP  steering  committee.  Your  charter  is  to  implement  a 
strategy  to  meet  the  long  term  non-tactical  information  processing 
requirements  of  Naval  afloat  and  ashore  operational  units. 
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VI.  TENTATIVE  CONCLUSIONS  AND  RECOMMENDATIONS 

A.     CONCLUSIONS 

The  realities  of  the  way  management  information  projects  are 
budgeted,  funded  and  implemented  in  the  Department  of  the  Navy  are 
not  unique.   The  command  structure,  billet  rotation  policies  and 
specialization  of  functional  tasking  do  give  these  processes  characteristics 
that  are  worthy  of  study. 

A  careful  review  and  discussion  of  the  case  study  in  chapter  5 
should  prove  a  fruitful  source  of  potential  pitfalls  that  face  a  large 
organization  trying  to  modernize  its  data  processing  capabilities.   Some 
of  the  pertinent  questions  that  may  be  raised  are: 

•  What  is  the  proper  level  of  authority  to  control  production  and 
integration  of  data  processing  programs? 

•  Is  data  modeling  a  workable  and  worthwhile  activity  and  if  so  at 
what  level  of  the  organization  should  it  be  accomplished? 

•  With  split  responsibility  for  production,  training  and  maintenance  of 
software  can  the  true  return  on  investment  for  updating  and 
integrating  software  be  calculated? 

•  Are  CASE  tools  adequately  developed  to  be  cost  effective  in  the 
Navy  software  development  process? 

•  If  CASE  tools  are  to  be  used  should  contracts  be  written  to  hold 
vendors  accountable  for  successful  transition  from  another  vendors 
product?   And  if  written  would  any  vendor  bid  on  them? 
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•  Can  a  poorly  prepared  survey  do  more  damage  than  good? 

•  Should  a  CASE  tool  be  utilized  that  generates  code  in  a  proprietary 
language  and  requires  run-time  modules  to  execute? 

B.     RECOMMENDATIONS 

These  recommendations  are  based  on  the  fact  that  the  funding 
environment  within  DOD  is  constrained.   Any  project  must  be  able  to 
prove  it  is  cost  effective  with  a  relatively  short  payback  period. 

•  If  data  modeling  is  to  be  done,  it  should  be  done  at  the  ship  wide 
level  to  allow  integration  of  ship  wide  requirements.  This  will  allow 
immediate  savings  in  reduction  of  support  for  parallel  systems. 

•  New  systems  developed  should  utilize  object  oriented  or  other 
designs  that  allow  enough  flexibility  to  readily  accept  technological 
advances. 
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APPENDIX  A 

This  document  is  the  cover  letter  and  edited  four  sections  of  the 
survey  sent  out  by  COMNAVSUPSYSCOM  to  SNAP  users. 
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AUTOVON 

IN  REPLY  REFER  TO 


0332 
4400 
24  MAY  1991 


From:   Commander,  Naval  Supply  Systems  Command 
To:     Distribution 

Subs:    SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT 

Ref :     (a)  Functional  Policy  Council  of  April  1991 

Encl:    (1)   Afloat  Business  Systems  Applications 
Comparison 

(2)  Type  Commander  SUADPS  Functional  Evaluation 

(3)  Type  Commander  SUADPS  Functional  Needs  Assessment 

(4)  Type  commander  SUADPS  Reports  Critique 

1.  Pursuant  to  agreements  made  during  the  April  1991  Functional  Policy 
Council,  a  comprehensive  evaluation  of  SUADPS  and  SNAP  II  Supply  and 
Financial  Management  system  strengths  and  weakness  is  underway.   The 
observations  and  recommendations  of  this  study  will  influence  the  manner 
in  which  NAVSUP  will  pursue  the  development  of  the  SNAP  Material 
Management  System  (SMMS).   To  assist  in  this  evaluation,  a  comprehensive 
review  of  applications  now  addressed  by  SUADPS  and  a  needs  assessment  of 
those  applications  not  now  included  in  SUADPS  are  required. 

2.  To  establish  a  baseline  by  which  to  measure  the  effectiveness  of 
our  current  supply  management  systems,  NAVSUP  recently  developed  an 
afloat  business  systems  applications  matrix.   This  matrix  totaled  219 
business  applications  considered  necessary  for  modern  afloat  supply 
operations.  NAVMASSO  compared  current  versions  of  SUADPS,  SFM,  OMMS, 
NALCOMIS  and  ILM  against  this  matrix.   NAVMASSO 's  findings,  enclosure 

(I),  are  forwarded  for  information.   NAVSEA  PMS-331  has  tasked  the  MRMS 
development  contractor  to  likewise  compare  MRMS  functionality  against 
the  matrix.   The  results  of  that  comparison  will  be  forwarded  for 
information  under  separate  cover.   Overall,  SUADPS  was  found  to  include 
automated  routines  for  only  109  of  the  219  business  applications. 

3.  To  assess  SUADPS  effectiveness,  a  questionnaire,  enclosure  (2),  is 
forwarded  for  each  business  application  (109)  now  included  in  the 
current  SUADPS  release.   Your  comments  on  each  application  will 
determine  whether  a  function  is  satisfactory  as  designed,  unsatisfactory 
and  in  need  of  redesign,  or  a  candidate  for  pierside  support  or  other 
off -ship  methods. 
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Sub j :  SNAP  II  SUPPLY  AND  FINANCIAL  MANAGEMENT  SYSTEM  FUNCTIONAL 
ASSESSMENT 

4.  For  each  application  not  now  automated  in  SFM  5.10  (122),  a 
questionnaire,  enclosure  (3),  is  also  included.   Your  comments  will 
influence  whether  this  application  will  be  automated  in  SMMS. 

5.  Finally,  your  assistance  is  requested  to  evaluate  the  appropriateness  of 
the  reports  now  included  in  SUADPS.   Your  comments  on  enclosure  (4)  will 
influence  whether  these  reports  will  be  continued  under  SMMS,  should  be 
repositioned  to  a  PC  MIS  environment,  or  dropped  from  use. 

6.  Completing  enclosures  (2),  (3)  and  (4)  will  require  a  thorough  insight 
into  he  strengths  and  weaknesses  of  SNAP  II  SFM  and  a  comprehensive 
understanding  of  how  afloat  supply  officers  and  staffs  now  manage  their 
affairs  with  the  help  of,  and  some  times  in  spite  of,  our  afloat  business 
information  management  systems.   Fleet  support  of  this  functional  assessment 
is  necessary  to  ensure  that  SMMS  addresses  our  mutual  needs  and  desires  and 
concentrates  on  delivering  the  greatest  benefit  for  our  investment. 


7.   It  is  requested  that  enclosures  (2), 
returned  to  NAVSUP  0332  by  15  July  1991. 


(3)  and  (4)  be  completed  and 


S.  W.  Baldwin 
Acting 


Acting 

Assistant  Commander 

Inventory  &  Systems  Integrity 


Distribution: 
COMSUBLANT  (NS) 
COMSUBPAC  (N5) 
COMNAVSURFLANT  (N7) 
COMNAVSURFPAC  (N7 ) 

Copy  to:  (w/o  ends) 
CINCLANTFLT  (N4 ) 
CINCPACFLT  (N4) 
NAVMASSO  (01) 
NAVSEA  (04-TD) 
NSCS  Athens  (48) 
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Page  No.        1 
05/24/91 

APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


Enclosure (1) 


APPLICATION 


SUADPS   SFM   OMMS   NALCOMIS  ILM 


BUSINESS  FUNCTION:  ALLOWANCE /TECH  DATA 


*  SUB  FUNCTION:  CONFIGURATION  MGMT 
BASELINE 

CONFIGURATION  CHANGES 

*  SUB  FUNCTION:  TECHNICAL  DATA 
TECH  MANUALS 

COMPONENT  CHARACTERISTICS 

*  SUB  FUNCTION:  ALLOWANCE 
APL  QA 

COMPUTATION  REVIEW 

FCFBR 

RANGE /DEPTH  ANALYSIS 

LOAD  LIST  EFFECTIVENESS 

*  SUB  FUNCTION:  ILO/DECK  LOAD  SUPPORT 
CHANGE  IN- FORCE  STRUCTURE 

REPAIR  PARTS  ANALYSIS 

CONFIGURATION  ANALYSIS 

TECHNICAL  DOCUMENTATION 

ANALYSIS 

LOAD  LIST  ANALYSIS 

LOGISTICS  READINESS 

2M  SUPPORT 


N 

N 

Y 

Y 

Y 

N 

N 

Y 

Y 

Y 

N 

N 

Y 

Y 

N 

N 

N 

Y 

N 

Y 

P 

N 

Y 

N 

Y 

Y 

N 

N 

Y 

Y 

N 

N 

N 

N 

N 

Y 

Y 

N 

Y 

Y 

Y 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

Y 

N 

N 

N 

N 

Y 

N 

N 

N 

N 

N 

N 

N 

N 

N 

Y 

N 

N 

N 

N 

Y 

N 

Y 

N 

N 

N 

38 


Page  No .   2 
05/24/91 

APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION 


CATEGORY 


SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  BUSINESS  OPERATIONS 


*  SUB  FUNCTION:  MATERIAL  REQUESTS 
ACCEPT  CUSTOMER  MATERIAL 
REQUESTS 

EDIT  MATERIAL  REQUESTS 

PROCESS  REQUIREMENTS  FOR 

ISSUE/REFERRAL 

MONITOR  REQUISITION  STATUS 

MODIFY,  CANCEL,  FOLLOW-UP 

REQUISITIONS 

NON-STANDARD  MATERIAL  REQUESTS 

RESCREEN 

CANNIBALI ZATIONS / PAYBACKS 

UNREP  PLANNING 

SERVICE  REQUESTS 

*  SUB  FUNCTION:  DLR  MANAGEMENT 
CARCASS  TRACKING 

2M  CHECKS/CERTIFICATION 
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*  SUB  FUNCTION:  EXPENDITURES 
MATERIAL  DISPOSITION 


DEFICIENT 
MATERIAL 


N 


MATERIAL  DISPOSITION 

HAZ  WASTE 

N 

MATERIAL  DISPOSITION 

EXCESS 

Y 

SCRAP 

N 

SURVEY  PROCESSING 

Y 

ROD  PROCESSING 

N 

QDR  PROCESSING 

N 

TDR  PROCESSING 

N 

*  SUB  FUNCTION:  EXPEDITING 

ID  HOT  REQUISITIONS 

N 

ON-LINE  MANAGEMENT 

Y 
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CASREP 
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NMCS/PMCS 
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HOT  JCN 
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Page  No.   3 
05/24/91 

APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 

APPLICATION  CATEGORY  SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  CONTROL 

*  SUB  FUNCTION:  CONSTANTS 

SYSTEM  CONSTANTS  Y 

VALIDATION  TABLES  Y 

LOCAL  CONSTANTS  Y 

COUNTERS  Y 

*  SUB  FUNCTION:  SECURITY 

USER  ACCESS  Y 

MAN  HOUR  ACCOUNTING  N 

MAN  HOUR  DATA  PER  TRANSACTION  N 

*  SUB  FUNCTION:  ADP  OPERATIONS 

BACK/UP  Y 

RECOVERY  Y 

ADP  SCHEDULING  Y 

SYSTEM  CONFIGURATION  MODULE            Y 

MANAGEMENT 

SUB  FUNCTION:     TRANSACTION  RECORDING 

PURGE  TO  HISTORY  Y       Y   N    P        N 

CTL  PROCESSING  Y       P   N    N        N 
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Page  No.   4 
05/24/91 

APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION 


CATEGORY 


SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  EXTERNAL  INTER  ACES 


*  SUB  FUNCTION: 

NALCOMIS 

OMMS 

MRMS 

IMMS 

UADPS 

UICP 

SCLSIS 

APADE 

DEPRA 

DDN 

PCMT 

ASCC 

ADM 

MSDS 

SAMS 

SPLICE 


ON-LINE  INTERFACES 


BATCH  INPUTS  FROM 


*  SUB  FUNCTION: 
CHANGE  NOTICE 
ASI 

COSAL 

AVCAL 

TARSLL 

FILL 

FAADC  TAPES  SFOEDL 

FAADC  TAPES  C&H 

FAADC  TAPES  OTHER 

RRTMIS 

E38 

ICP  DEMAND 

CYCLIC  ASSET 

*  SUB  FUNCTION:  BATCH  INPUTS  TO 
RRIMIS 

CYCLIS  ASSET 

PMO 

PARENT  TENDER 

*  SUB  FUNCTION:  BATCH  INPUTS  TO /FROM 
SNAP  II 
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Page  No.   5 
05/24/91 

APPLICATIONS  FOUND  IN  V   IOUS  AFLOAT  BUSINESS  SYSTEMS 

APPLICATION  CATEGORY  SUADPS   SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  FINANCIAL 

*  SUB  FUNCTION:  OM,N 
SHIP'S  GRANT  ACCOMMODATION 
DEPARTMENTAL  BUDGET  MANAGEMENT 
SHORE  LIST  PROCESSING 
TRANSMITTALS  ASHORE 

PROJECT  ACCOUNTING 

BUDGET  FORECASTING 

BUDGET  EXECUTION  GRAPHICS 

REPORT  OF  CREDITS 

ROV  AVAILABILITY  COST  REPORT 

FLIGHT  HOUR  ACCOUNTING 

*  SUB  FUNCTION:  NAVY  STOCK  FUND 
TRANSMITTAL  OF  NSF  DETAIL 
ASHORE 

FAADC  RECONCILIATION  DATA 

PROCESSING 

SAC  224  PROCESSING 

*  SUB  FUNCTION:  OTHER  ACCOUNTING 
OPN  ACCOUNTING 

SCN  ACCOUNTING 
TOB  ACCOUNTING 
SHIP'S  STORE  ACCOUNTING 
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Page  No.   6 
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APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION 


CATEGORY 


SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  I-LEVEL  MAINT  SUPPORT 


*  SUB  FUNCTION:  COMPONENT  CONTROL 

INDUCTIONS 

REPAIR  AND  RETURN 

CANNIBALIZATIONS / PAYBACKS 

CONDITION  CODE  TRANSFERS 

El  MANAGEMENT 

RFI  RETURN 

NRFI  RETURN 

FLR  MANAGEMENT 

2M  MANAGEMENT 

AWP  MANAGEMENT 

MAINTENANCE  ACTION  REPORTING 
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Page  No.   7 
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APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION  CATEGORY 

**  BUSINESS  FUNCTION:  INVENTORY 


*  SUB  FUNCTION:  MAINTAIN  DATA 

UPDATE  MANAGEMENT  DATA 

MAINTAIN  INVENTORY  BALANCE  BY 

LOCATION 

MAINTAIN  INVENTORY  BY  OTHER 

VARIABLES 

MAINTAIN  INVENTORY  BY  OTHER 

VARIABLES 

MAINTAIN  INVENTORY  BY  OTHER 

VARIABLES 


BY  LOT 


CONTPACT 
NUMBER 
SHELF   LIFE 
EXPIRATION 


SUADPS  SFM  OMMS  NALCOMIS  ILM 
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*  SUB  FUNCTION:  MANAGE  STOCK  LISTS 
DEMAND  HISTORY  COLLECTION 

LEVEL  SETTING 

REPLENISH 

EXCESS  MANAGEMENT 

*  SUB  FUNCTION:  VALIDITY  FUNCTIONS 
PHYSICAL  INVENTORY 
RECONCILIATION 

CAUSATIVE  RESEARCH 
ADJUSTMENTS 

*  SUB  FUNCTION:  SPECIAL  INVENTORIES 
SEAMART 

FUEL 

SHELF  LIFE  MATERIAL 

SUSPENDED  MATERIAL 

GAS  AND  CYLINDERS 

HAZMAT 

Q  COSAL  MATERIAL 

DLRS 

LEVEL  I/SUBSAFE 

NUKE  WATER  CHEMICALS 

AMMUNITION 

LOCAL  ROTABLE  POOL  ASSETS 

EQUIPAGE  MHE 

EQUIPAGE  CONTROLLED     EQUIPAGE 

EQUIPAGE  OTHER     CRITICAL 

MAMS 

OSI/RSS 

GPETE/SPETE         CALIBRATION     LAB 

PROVISIONS 

SHIPS  STORE  1Q  COG  MATERIAL 

PRE-EXPENDED  BIN  MATERIAL 

OUTBOUND  PACKUP 

INBOUND  PACKUP 
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APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 

APPLICATION  CATEGORY  SUADPS  SFM  OMMS  NALCOMIS  ILM 


STRATEGIC  WEAPONS  MATERIAL 
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Page  No.   9 
05/24/91 

APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION 


CATEGORY 


SUADPS  SFM  OMMS  NALCOMIS  ILM 


BUSINESS  FUNCTION:  PERFORMANCE  MONITORING 


*  SUB  FUNCTION:  INVENTORY 
DEMAND  EFFECTIVENESS 
ALLOWANCE  EFFECTIVENESS 
UMMIPS  PERFORMANCE 
RANGE /DEPTH  ACCURACY 
INVENTORY  ACCURACY 
CAUSATIVE  RESEARCH  RESULTS 

*  SUB  FUNCTION:  FINANCIAL 
NSF  STATUS 

BUDGET  EXECUTION 
ADJUSTMENT  MEASUREMENT 

*  SUB  FUNCTION:  WORKLOAD 
ACTION  PROCESS  TIME 

AVG  CUSTOMER  WAIT  TIME 
EXCEPTION  MEASUREMENT 
ENDURANCE 
PERSONAL  WORKLOAD 
PERSONAL  PRODUCTIVITY 
QA  PROGRAM 


Y 

Y 

N 

P 

N 

Y 

Y 

N 

Y 

N 

Y 

N 

N 

P 

N 

Y 

Y 

N 

Y 

N 

Y 

Y 

N 

N 

N 

N 

N 

N 

N 

N 

P 

Y 

N 

N 

N 

N 

Y 

N 

N 

N 

N 

Y 

N 

N 

N 

N 

N 

N 

Y 

N 

N 

N 

N 

Y 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

SUB  FUNCTION: 
RRTMIS 
PROCESS  CONTROL 


PHYSICAL  DISTRIBUTION 


N 

N 

N 

N 

N 

N 

N 

N 
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APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 
APPLICATION  CATEGORY  SUADPS   SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  PHYSICAL  DISTRIBUTION 


*  SUB  FUNCTION:  INBOUND  MATERIAL 
RECEIPT  IN  PROCESS 
CHARACTERISTICS 

RECEIPT  IN  PROCESS 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

CHARACTERISTICS 

STAGING  FOR  TURNOVER 

STAGING  FOR  STOW 

STOW 

STOW 

PROOF  OF  DELIVERY 

*  SUB  FUNCTION:  STOREROOM  MGMT 
STOWAGE  PLAN 

LOCATION  CHARACTERISTICS 
LOCATION  CHARACTERISTICS 
LOCATION  CHARACTERISTICS 
LOCATION  CHARACTERISTICS 
LOCATION  CHARACTERISTICS 
LOCATION  CHARACTERISTICS 

RESTOWAGE 
LABELLING 
LABELLING 


Y 

Y 

N 

Y 

Y 

LOT  SIZE 

N 

N 

N 

N 

Y 

CONT   CT 

N 

N 

N 

Y 

Y 

NUMBER 

PACK   ATE 

N 

N 

N 

N 

Y 

SHELF  LIFE 

N 

N 

N 

N 

Y 

N 

N 

N 

N 

Y 

CUBE 

N 

N 

N 

N 

Y 

DESTINATION 

N 

Y 

N 

N 

N 

N 

Y 

N 

N 

N 

N 

Y 

N 

N 

Y 

CLEAN 

N 

Y 

N 

N 

Y 

N 

Y 

N 

N 

N 

N 

Y 

N 

Y 

N 

N 

N 

N 

N 

N 

SIZE 

N 

Y 

N 

N 

N 

SECURITY 

N 

N 

N 

N 

N 

WEIGH   LIMITS 

N 

N 

N 

N 

N 

CUBE   LIMITS 

N 

N 

N 

N 

N 

TYPE    MATERIAL 

N 

Y 

N 

N 

N 

MATL 

N 

Y 

N 

N 

N 

COMPATIBILITY 

N 

Y 

N 

N 

N 

MATERIAL  INFO 

Y 

Y 

N 

N 

Y 

STOW    CATION 

Y 

Y 

N 

N 

Y 
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APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 
APPLICATION  SUADPS  SFM  OMMS  NALCOMIS  ILM 


*  SUB  FUNCTION:  OUTBOUND  MATERIAL 

PICK 

STAGE 

PREPARE  DOCUMENTATION 

PACK/ CRATE 

RETROGRADE  HANDLING 

PROOF  OF  SHIPMENT 

TRANSHIPMENTS 

ENGINEERING  INVESTIGATIONS 

TURN- INS 

TURN- INS 

TURN- INS 

TURN- INS 


Y 

N 

N 

Y 

N 

P 

N 

N 

N 

N 

Y 

N 

N 

Y 

N 

N 

N 

N 

N 

N 

Y 

N 

N 

Y 

N 

N 

Y 

N 

N 

N 

N 

Y 

N 

N 

N 

N 

N 

N 

Y 

N 

MTIS 

Y 

Y 

N 

Y 

Y 

SUPPLY 

CENTER   Y 

Y 

N 

N 

Y 

DRMO 

Y 

Y 

N 

N 

N 

DLRS 

Y 

Y 

N 

Y 

N 

*  SUB  FUNCTION:  PLANNING 
WORKLOAD  SCHEDULING 
PHYSICAL  CONSTRAINTS 
T-SHED  BACKLOAD  MANAGEMENT 
UNREP  PLANNING 
UNREP  PLANNING 
UNREP  PLANNING 
UNREP  PLANNING 


P 

N 

Y 

Y 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

PROVISIONS 

Y 

N 

N 

N 

N 

BULK 

Y 

N 

N 

N 

N 

BIN 

Y 

N 

N 

N 

N 

TURNOVER 

Y 

N 

N 

N 

N 
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Enclosure  (2) 

TYPE  COMMANDER  SUADPS  FUNCTIONAL  EVALUATION 

BUSINESS  FUNCTION:  90  sheets  total 

SUB  FUNCTION:  one  for  each 

APPLICATION:  Y  under  SUADPS 

CATEGORY:  in  enclosure  (1) 

EVALUATOR : 


COMMAND/CODE/TELEPHONE : 


NO  YES 

l.a.  Is  this  application  necessary?  12    3    4 

l.b.  If  2,  3,  4,  why?  (rank  in  order  of  importance:  A,  B,  C,  D) 

Needed  for  supply  officer  or  staff  decision  making:   

Needed  for  customer  decision  making  or  information:   

Needed  for  internal  process  control:  

Needed  for  external  reporting:  

Needed  for  internal  higher  management  reporting:      


2.  Is  this  application  easy  to  use?  1 

3.  Do  operators  have  to  "trick"  the  system  to  get  this 
application  to  work?   If  2,  3,  or  4  explain:        1 


3.  Is  OJT  sufficient  training  for  operators  to  become 
proficient  in  the  use  of  this  application?         1 

4.  Is  "Shiprider"  assistance  necessary  to  successfully 
use  this  application?  1 

5.  Are  clear  instructions  available  on  how  to  use  this 
application?  1 

6.  Do  problems  frequently  occur  using  this  application? 
If  2,  3,  or  4 ,  explain:  1 


7.    Does  this  application  provide  sufficient  12    3    4 

information?   If  1,  2,  or  3 ,  explain  what  is  missing. 


8.    Should  this  business  application  be  done  ashore?    12    3    4 
If  3  or  4,  explain  how: 


9.    What  improvements  would  you  suggest  for  any  aspect  12    3    4 
of  this  application? 
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Enclosure  (3) 

TYPE  COMMANDER  SUADPS  FUNCTIONAL  NEEDS  ASSESSMENT 

BUSINESS  FUNCTION:  108  sheets  total 

SUB  FUNCTION:  one  for  each 

APPLICATION:  N  under  SUADPS 

CATEGORY:  in  enclosure  (1) 

EVALUATOR : 


COMMAND /CODE /TELE PHONE : 


THIS  APPLICATION  IS  NOT  IN  SUADPS  BUT  MAY  BE  PLANNED  FOR  A 
LATER  RELEASE  PLEASE  ANSWER  THE  FOLLOWING  QUESTIONS: 

NO  YES 

l.a.  Should  this  application  be  automated  in  SUADPS?     12    3    4 

l.b.  If  2,  3,  4,  why?  (rank  in  order  of  importance:  A,  B,  C,  D) 

Needed  for  supply  officer  or  staff  decision  making:   

Needed  for  customer  decision  making  or  information:   

Needed  for  internal  process  control:  

Needed  for  external  reporting:  

Needed  for  internal  higher  management  reporting:      


What  information  should  this  application  provide? 


In  what  form  should  the  information  be  provided? 


4.    Is  this  application  now  performed  manually? 

4.  a.  If  3  or  4,  what  skill  level  is  needed  to  accomplish 

the  task? 
Officer         CPO  LPO  PO  SN 


4.b.  If  3  or  4,  how  often  is  this  application  accomplished? 

Deployed: 

Annually  Monthly  Weekly  Daily  


In  home  port : 

Annually  Monthly  Weekly  Daily  

During  Availabilities: 

Annually  Monthly  Weekly  Daily  

5.    Has  this  application  been  automated  with  the  use  of  locally 
developed  software? 


50 


SUADPS  MANAGEMENT  REPORTS  ANALYSIS 


TYGGM: 

Ed  FLNCTEIT 


EVAIUATOR: 
KEKKT  FULL  NAME 


KEQUISTIICN  FILE  PRINT 

ISSUE  PENDING  FILE  (RfcHKT  2) 

008  SAMMA/SAL 

008  SAMMA/SAL  FART  1  TOIAL  DETAIL 

008  SAMMA/SAL  FART  2  DOLLAR  VALUE  BY  AT  CODE 

008  SAM^/SAL  PART  3  NSA  EETAIL  REPORT 

008  SAMMySAL  PART  4  APA  PGNT  OF  SAL  EETAIL 

008  SAM-5VSAL  PART  5  INVENTOR  MANAGEMENT 

009  CGSAL  APL  ANALYSIS  (USID  C  &  M) 
009  CDSAL  PERCENTAGE  (USID  A,  B,  T) 
009  OGSAL  PERCENTAGE  (USTD  C  AND  M) 
009  AVCAL  PJC  ANALYSIS 

009  AVCAL  PERCENTAL 

Oil  MASTER  STOCK  STATUS 

015  OPTAR  HISTORY  FILE  PROCESSING  REPORT 

036  ISSUES  CF  OCNIROIIED  ERDG  SUBSTANCES 

044  PMO  DEMAND  REPORT 

051  EXCESSIVE  LOCATIONS  LISTING 

051  LOCATION  AUDIT  LISTING 

051  MAIL  GN  HAND  -  NO  LOCATION 

051  MSP  MATERIAL  -  H3CNECUS  LOCATTGN  LISTING 

051  GUANTTTY  VALIDATIGN  (PART  ONE) 

051  CL^NITIY  VALIDATION  (PART  TWO) 

054  DLR  PRINT  REPORT 


USE  OOCES:     RE      RHJUIREU  EXTERNAL        FREQUENCY  GOCES:  D    DALLY 

RI      REQUIRED  TNTERNAL  M    MONTHLY 

IM       INTERNAL  MANAGEMENT  Y     YEARLY 


W    WEEKLY 
Q    QUARTERLY 
A    AS  REQUIRED 
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SUADPS  MANAGEMENT  REPORTS  ANALYSIS 


TYCEM:  

di  functtcn~ 


FJVALUATOR: 

"REFCRT  FULL  NAME 


TJ£E~ 

code 


056  MATERIAL  CBLIGAITCN  VALIDATION  OPTTCN  1 

056  MATERIAL  CBLIGKITCN  VAIIDATION  OPTTCN  2 

056  MATERIAL  CBLKaUCK  VAUDKITEN  OPTTCN  3 

056  MATERIAL  CBLIGKTICN  VALIDATION  CPITCN  4 

056  MATERIAL  CBLIGKEECN  VAULYflTCN  OPTTCN  5 

056  MATERIAL  CBLKKHCN  VAIJDATTCN  OPTTCN  6 

056  MATERIAL  CBLTCKEXCN  VAIIDATION  OPTTCN  7 

057  DEMAND  REPORTING 

058  DEPOT  LEVEL  REPAIRABLE  CARCASS  TRACKING 

060  CCtHOLIDATED  PACKUP  LISTING 

061  REQN  RESPONSE  TIME  MIS 

062  UMEPS  KFFCFMMCE  REPORT 
064  QUARTERLY  ASSET  REPORT 

064  TYODM  REPCRT 

065  EXTENDED  MONEY  VAUJE  OF  DID  RECUISTTTCNS 

071  DID  LUES  WITH  MATERIAL  CN  HAND 

072  AUTCMATIC  FOLLOW-UP  READY  FDR  RELEASE 

073  DEMAND  HLSIDRY  PROCESSING  REPCRT 

074  DEMAND  TAPE  CNE-LTNE 

080  MASTER  STOCK  STATUS  AND  LOCATCR  LISTING 

083  OFFLOAD  EY  EXTENDED  MONEY  VALUE 

084  INVENTORY  PROGRESS  REPORT 

084  POTENTIAL  GAINS  AND  LOSSES  BY  INVENIDRY 

09CM  BMF  RECORD  rFTFTF. 

09CR  RECUISTTTCN  PRTNTCUT 


OF 

CDCE 


USE  CODES:  RE 
RT 
IM 


REQUIRED  EXTERNAL 
REQUIRED  INTERNAL 
INTERNAL  MANAGEMENT 


FREQUENCY  CODES: 


D    DAILY 
M    MONTHLY 
Y    YEARLY 


W    WEEKLY 
Q    QLPRTERLY 
A    AS  REQUIRED 
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SUADPS  MANAGEMENT  REPORTS  ANALYSIS 


TYCOM: 

EC  FUNCTION 


EVAIIJATOR: 
"REPCRT  FULL  NAME 


IKE- 

code 


091  SURFACE  MAINTENANCE  LATA  SYSTEM  REPORTING 

093  GROUP  CANTHJATICy  REQUEST 

094  KHl'.lPl'  IN  PROGRESS 

096  AVIATION  MAINTENANCE  DATA  SYSTEM  REPCRTTNG 

100  CCMMANDING  OFFICER'S  BUDGET  (FEPORT  21) 

100  DEPARTMENT  BUDGET  (REPORT  21) 

100  DIVISION  BUDGET     (REFCRT  21) 

100  INVENTORY  ADJUSTMENT  KEKKT 

100  REFCRT  03  FINANCIAL  INVENTORY  REFCRT 

100  REFCRT  04  MCNIHLY  RECEIPT  REFCRT 

100  REFCRT  04  MONTHLY  RECErPTS  REFCRT 

100  REFCRT  05  MONTHLY  TRANSFER  TO  DISFCSAL 

100  REFCRT  05  OSO  TRANSFER 

100  REFCRT  06  NC  2074  CHARGES 

100  REFCRT  07/08  NAVCOMPT  176  NSA  ROV  A&B  SUM 

100  REFCRT  09  NAVCCMFT  FORM  2051 

100  REFCRT  10  SUPPLY  EFFECTIVENESS  REFCRT 

100  REFCRT  20  UNFILLED  ORDER  SUMMARY 

100  REFCRT  22  OEOGATED/EXFBCED  DIFFERENCES 

100  REFCRr  23  PRICR  FISCAL  YEAR  TRAN3ACTICN 

100  REFCRT  24  MSG  REFCRT  OF  CREDITS 

100  REFCRT  26  FLIGHT  CSS  BUDGET  OFTAR 

100  REFCRT  28  AFM  BUDGET  OPTAR 

100  REFCRT  34  INVENTORY  ADJUSTMENT  REPORT 

100  REFCRT  41  SUPPORT  UNITS  BOR 


OF 

cctE 


USE  CODES:  RE 
RI 
IM 


REQUIRED  EXTERNAL        FREQUENCY  COCES:  D    DALLY 

INTERNAL  M    MONTHLY 

MANAGEMENT  Y     YEARLY 


W    WEEKLY 
Q    QLFRTERLY 
A    AS  FS3UIRED 
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SUMPS  MANAGEMENT  REPORTS  ANALYSIS 


TYCOM:  

nr  ructtck" 


EVALUATOR: 
"REPORT  FULL  NAME 


TSET 
CODE 


100  REKRT  42  RETMBLRSABLE  BUDGET  OPTAR 

100  KhKKi'  46  ROV  AVALLARTT  .TTY  COST  REPORT 

100  REPORT  47  SUPPLIES  AND  EQUIPAGE  BCR 

100  REPORT  49  USED  B  AND  T 

100  SAC  207  KLRK1S 

100  STOCK  ASSET  DOLLAR  VALUE  EXTENSION 

100  SUMMARY  FIELD  ObIIR/E<FENDDC  DTFF  LIST 

100  SUPPORTED  UNITS  F£R  MSG 

101  FIXED  ALLOWANCE  MANAGEMENT  REVIEW  REKRT 
CRH  CLM  RECEIPT  FILE  PR0CE3ST1G  REKRT 

CTL  FINANCIAL  TRANSACTICM  LEDGER 

CTL  MATERIAL  TRANSACTION  REPCRT 

CTL  QCCSAL  T^JSAOTON  REPCRT 

CTL  REQUISITION  TRMEACTTON  LEDGER 

FBM  POAPIS/KHEIDCN  ttE  REPCRT 

MVT  MASTER  VALTDATICN  TABLE  TRINTCUr 

CSO  CLMJIATIVE  CSO  FILE  PROCESSING  REKKT 

CSTAR  ORDER  AND  SHIP  TIME  ANALYSTS 

PEC  BATCH  RECEIPT 

RFH  CLM  FISCAL  YR  TD  DATE  RECEIPT  LISTING 

SSP  SUSPENDED  TRANSAdTCN 

SUNDCR  SUMMARIZATION  OF  UNAUTHORIZED  CN  CRCER 

SUNDCR  CANCELLED  STOCK  HEMS  OVER  30  DAYS 

SUNDCR  CANLTrDATES  FOR  PARITAL/FULL  CANCEIIATTCN 


FPOTENCY 

OFUSE 

CODE 


USE  CDCES:  RE 
RE 
IM 


REQUIRED  ECTERNAL        FREQUENCY  CCCES:  D    DAILY 
REQUIRED  INTERNAL  M    MONTHLY 

INTERNAL  MANAGEMENT  Y     YEARLY 


Vv    WEEKLY 
Q    QUARTERLY 
A    AS  REQUIRED 
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SUADP3  MANAGEMENT  REPORTS  ANALYSIS 
TYCOM:  EVAILATCR:     . „___ 

di  functtck      repcrt  full.name  use 

oxe 


UNMEX  CARCASS  DETAIL  REPORT 

UNMEX  ADJUSTED  CANCELLATIONS 

11MEX  UNMATCHED  CAPTICNS  C,  H  AND  J 

UN-JEX  UNMATCHED  EXPENDITURE 

ttWEX  UNMATCHED  EXPENDITURE  ADJ  SUMMARY 

UNMEX  ttMSX  FRDCESSING  SUMMARY 

UITLITY  AMI  TRANSFER  KEKKT 

urruiY  ISSUE  FENDING  FILE  (REPORT  3) 

X43  SURVEY  REPORT 

X43  QCDSAL  SURVEY  REKKT 

X49  MAINTAINING  CURRENCY  OF  APFROFRIAITNG 

X49  DATA 

X84  POTENTIAL  GAIN/LOSS  FROM  SCHED  INVENTCRY 

X84  BATCH  ERROR  REPORT 

ZOC  REQUISITIONS  REQUIRING  IOCAL  PROCUREMENT 

ZOC  TRANSACTIONS  RELEASED  TO  PARENT  TENTED 

ZOC  TRANSACTIONS  RELEASED  FRCM  SUPPLY 


OF 
OOCE 


USE  COCES:     RE      REQUIRED  EXTERNAL        FREQUENCY  COLES:   D    DAILY  W    WEEKLY 

INTERNAL  M    MONTHLY      Q    QUARTERLY 

MANAGEMENT  Y     YEARLY        A    AS  REQUIRED 
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APPENDIX  B 

This  document  is  a  collection  of  the  cover  letters  sent  in 
response  to  survey  in  appendix  A. 
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DEPARTMENT    OF    THE   NAVY 

COMMANDER    SUBMARINE    FORCE 

U    S   ATLANTIC    FLEET 

NORFOLK   VIRGINIA    23511-5230 


4400 

Ser 

N514/6 
374 

08  JUL 
1991 


From: 
To: 

Subj  : 
FUNCTIONAL 


Commander  Submarine  Force,  U.S.  Atlantic  Fleet 
Commander,  Naval  Supply  Systems  Command  (Code  0332) 

SNAP  II  SUPPLY  AND  FINANCIAL  MANAGEMENT  SYSTEM 

ASSESSMENT 


Ref:   (a)  Commander,  Naval  Supply  Systems  4400  Ser  0332  of 

24  May  1991 

Encl:  (1)  Type  Commander  SNAP  II  SFM  Functional  Evaluation 

(2)  Type  Commander  SNAP  II  SFM  Functional  Needs 
Assessment 

(3)  Type  Commander  SNAP  II  SFM  Reports  Critique 

1.  In  response  to  reference  (a),  enclosures  (1)  through  (3)  are 
forwarded.   Some  of  the  forms  in  the  enclosures  were  left  blank  due  to 
the  ambiguous  nature  of  the  application  or  sub-function  description.   We 
would  be  happy  to  comment  if  the  ambiguities  can  be  clarified. 

2.  Our  position  remains  that  of  supporting  and  improving  the  current 
SNAP  II  software  found  in  SFM,  as  well  as  the  Maintenance  Data  Subsystem 
(MDS) ,  rather  than  creating  entirely  new  software.  Although  the  current 
software  is  not  without  it's  problems,  we  feel  that  incremental  change 
is  the  only  realistic  approach  to  solving  them. 


My  point  of  contact  is  SKCS(SS)  E 
564-6783  or  Commercial  (804)  444-6781. 


Bures,  Code  N514,  AUTOVON 


Copy  to:  (w/o  ends) 
CINCLANTFLT  (N4 ) 
NAVMASSO  (01) 
NAVSEA  (04-TD) 
NAVSEA  (PMS-3  31) 


D.N.DOYLE 
By  direction 


57 


DEPARTMENT    OF    THE   NAVY 

COMMANDER   NAVAL    SURFACE    FORCE 

UNITED   STATES    PACIFIC    FLEET 

SAN    DIEGO,    CALIFORNIA    92155-5035 

4400 

Ser  N7/7469 
15  AUG  !99] 

From:   Commander,  Naval  Surface  Force,  U.  S.  Pacific  Fleet 
To:     Commander,  Naval  Supply  Systems  Command 

Subj     SNAP  II  SUPPLY  AND  FINANCIAL  MANAGEMENT  SYSTEM  FUNCTIONAL 
ASSESSMENT 

Ref:     (a)  COMNAVSUPSYSCOM  ltr  0332  4400  of  24  May  1991 

End:    (1)   SNAP  II  Supply  and  Financial  Management  Reports  Analysis 

(2)  Type  Commander  SNAP  II  Supply  and  Financial  Functional 
Evaluation 

(3)  Type  Commander  SNAP  II  Supply  and  Financial  Functional  Needs 
Assessment 

(4)  Concept  of  Operations 

1.  Pursuant  to  agreements  made  during  the  April  1991  Functional  Policy 
Council,  reference  (a)  provided  a  matrix  of  afloat  business  system 
applications  for  review.   In  addition,  reference  (a)  forwarded 
questionnaires  in  regard  to  each  business  application  now  included  in 
the  current  5.10  release,  for  those  not  now  automated  in  SFM  5.10,  and 
with  regard  to  SNAP  II  Supply  and  Financial  Management  Reports.   As 
requested  by  reference  (a),  enclosures  (1),  (2),  and  (3)  have  been 
completed  and  are  returned. 

2.  Enclosures  (1),  (2),  and  (3)  were  reviewed  and  completed  by  members 
of  COMNAVSURFPAC s  Supply  Maintenance  Mobile  Training  Team  (SMTT) ,  all 
experts  in  shipboard/staff  applications  of  SNAP  II  SFM  and  MDS.   SMTT 
comments  are  reflected  in  pencil  on  each  questionnaire.   Having 
developed  their  expertise  in  the  shipboard  environment,  the  comments 
provided  in  pencil  on  enclosures  (I),  (2),  and  (3)  are  necessarily 
bounded  by  existing  SNAP  II  SFM/MDS  environmental  constraints. 

3.  Subsequent  to  SMTT  review  and  comment,  the  enclosures  (2)  and  (3) 
questionnaires  were  subjected  to  a  second  review  at  the  COMNAVSURFPAC 
management  (0-5/0-6)  level.   The  intent  of  this  second  review  was  to 
explore  business  application  development,  taking  into  consideration 
environmental  constraints  redefined  by  technological  advances  including, 
for  example,  analog  and/or  digitized  data  transmission  via  satellite. 
In  such  environment,  the  opportunities  for  ships  becoming  Transaction 
Item  Reporting  (TIR)  activities  are  significant.   Enclosure  (4)  provides 
the  applicable  concept  of  operations.   Through  such  advances 
considerable  workload  can  be  moved  ashore  to  pierside  support  activities 
while  continuing  only  those  functions  aboard  ship  that  directly 
contribute  to  shipboard  combat  capability.   Those 
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applications  which  have  potential  for  being  moved  ashore  through  the  TIR 
concept  have  been  appropriately  annotated  in  red  ink  for  consideration 
in  future  development. 

4.   COMNAVSURFPAC  Point  of  Contact  is  LT  S.  Smith,  SC,  USN,  Code 
714/SMTT,  A/V  526-5789/commercial .  (619)  556-5789  or  CAPT  R.  Gunderson, 
SC,  USN,  N7,  A/V  577-2410/commercial  (619)  437-2410. 


R  .    H .  GUNDERSON 
By  direction 

Copy  to: 

CINCPACFLT  (41) 
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TIR  CONCEPT  OF  OPERATIONS 

The  concept  of  operations  proposed  in  paragraph  three  of  the  basic 
letter  incorporates  satellite  communications  technology  to  move  workload 
ashore  and  reduce  inventory  investment  afloat.   A  basic  outline  of  the 
concept  is  provided  as  follows: 

-  The  SNAP  II  SFM  file  as  it  exists  aboard  ship  today  will  be  moved 
ashore  to  the  Pierside  Support  Activity.   The  ship  will  be  furnished  with  c 
automated  inventory/location  file  showing  minimal  data  elements  to  include 
NSN,  Nomenclature,  On  Hand  balance,  and  location; 

-  The  ship  will  transmit  transaction  item  reports  via  satellite 
communications  at  scheduled  times  to  the  Pierside  Support  Activity.   Data  v. 
include  receipt  and  issue  transactions,  DTO  requisitions,  and  responses  to 
specific  Pierside  Support  Activity  data  inquiry  (e  .  g.,  location/count 
inventory  directives,  etc.)  transactions  previously  transmitted  to  the  shif 
via  satellite  communications. 

-  The  Pierside  Support  Activity  will  maintain  the  ship's  SNAP  II  SFM 
data  base,  generate  all  financial  reports/listings,  run  levels,  generate 
reorders/replenishment  requisitions,  process  ship  DTO  requisitions  into  the 
supply  system,  and  otherwise  dialogue  with  the  shore  supply  and  finance 
establishment  in  resolving  issues.   The  ship  will  be  responsible  for  issuir 
material  from  its  storerooms  and  receiving  material  into  its  storerooms,  ar 
TIR'ing  such  transactions  to  the  Pierside  Support  Activity  via  satellite 
communications.   Transactions/adjustments  to  shipboard  inventory/ location  fl 
will  be  accomplished  by  TIR  from  the  Pierside  Support  Activity  via  satellit 
communications . 

-  Shipboard  issues,  receipts,  and  directed  inventories  would  be 
accomplished  using  barcode  scanning  equipment,  storing  all  transactions  foi 
automatic  download  to  communications  equipment  and  transmission  via 
communications  satellite. 

Using  existing  technology,  this  concept  of  operations  significantly  simplii; 
the  afloat  storekeepers  daily  workload,  reducing  it  to  one  of  receiving, 
issuing,  inventorying  as  directed,  and  transmitting  data.  Workload  reduct:. 
afloat  would  be  used  to  realign  manpower  to  staff  Pierside  Support  Activit: 
Total  visibility  of  assets  afloat  would  also  provide  significant  opportunit 
for  inventory  investment  savings  afloat  (e.  g.,  insurance  items  need  no  lc: 
be  stocked  in  every  COSAL  but  perhaps  in  only  one  COSAL  of  ships  operating, 
close  proximity.) 

While  the  above  addresses  the  shipboard  repair  part/general  stores  SFM 
function,  it  has  equal  applicability  to  the  food  service/provisions,  ships 
store,  personnel,  and  disbursing  functions  as  well  as  to  various  Maintenanc 
Data  System  functions. 
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DEPARTMENT    OF    THE    NAVY 
COMMANDER   NAVAL    SURFACE    FORCE 
UNITED    STATES    ATLANTIC    FLEET 
NORFOLK,    VIRGINIA   23511-5215 

4000 

Ser  N752/63410 

8  JUL  1991 

From:   Commander,  Naval  Surface  Force,  U.S.  Atlantic  Fleet 
To:     Commander,  Naval  Supply  Systems  Command 

Subj  :    SNAP  II  SUPPLY  AND  FINANCIAL  MANAGEMENT  SYSTEM  (SFM) 
FUNCTIONAL  ASSESSMENT 

Ref:     (a)  COMNAVSUPSYSCOM  ltr  0332  44400  of  24  May  91 

Encl:    (1)  Type  Commander  SNAP  II  SFM  Functional  Evaluation 

(2)  Type  Commander  SNAP  II  SFM  Functional  Needs  Assessment 

(3)  Type  Commander  SNAP  II  SFM  Reports  Critique 

1.  In  accordance  with  reference  (a),  enclosures  (1)  through  (3)  are 
submitted  to  assist  in  completing  the  functional  assessment  of  SNAP 
Material  Management  Systems  for  future  afloat  use. 

2.  COMNAVSURFLANT  point  of  contact  SKCS(SW)  McGourn,  N7521,  commercial 
(804)  444-5816,  AUT0VON  564-5816. 


J.  W.  FREEMAN,  JR 
By  direction 
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DEPARTMENT    OF    THE    NAVY 

COMMANDER    SUBMARINE    FORCE 
UNITED    STATES    PACIFIC    FLEET 
PEARL   HARBOR,    HI    96860-6550 

4400 

Ser  5121/005008 
24  JUL  1991 

From:    Commander  Submarine  Force,  U.S.  Pacific  Fleet 
To:      Commander,  Naval  Supply  Systems  Command  (033) 

Subj  :     SNAP  II  SUPPLY  AND  FINANCIAL  MANAGEMENT  SYSTEM 
FUNCTIONAL  ASSESSMENT 

Ref:      (a)  COMNAVSUPSYSCOM  ltr  Ser  0332-4400  of  24  May  91 

Encl:     (1)  SNAP  II  Supply  and  Financial  Management  Reports 
Analysis 
(2)  Type  Commander  SNAP  II  Supply  and  Financial  Functional  Evalua': 

1.  The  functional  assessment  enclosed  in  reference  (a)  has  been 
reviewed  and  is  returned  with  requested  responses  as  enclosures  (1)  and 
(2)  . 

2.  COMSUBPAC  point  of  contact  is  LT  Dana  Ivey  (Code  5121)  who  may  be 
reached  at  A/V  471-8111  or  COML  (808)  471-0464/9034. 


D.  R.  LENGKEEK 
By  direction 
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DEPARTMENT    OF    THE   NAVY 

COMMANDER    NAVAL    SURFACE    FORCE 

UNITED    STATES    PACIFIC    FLEET 

SAN   DIEGO,    CALIFORNIA    92155-5035 

4400 

Ser  713/7059 
30  JUL  1991 

From:   Commander,  Naval  Surface  Force,  U.S.  Pacific  Fleet 
To:     Commander,  Naval  Supply  Systems  Command 

Subj  :    SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT 

Ref:     (a)  COMNAVSUPSYSCOM  ltr  0332  4400  of  24  May  91 

Encl:    (1)  Type  Commander  SUADPS  Functional  Evaluation 

(2)  Type  Commander  SUADPS  Functional  Needs  Assessment 

(3)  Type  Commander  SUADPS  Reports  Critique 

1.  The  SUADPS  Functional  Evaluations,  Needs  Assessments,  and  Report 
Critiques  forwarded  by  reference  (a)  were  reviewed  in  depth  by  five 
COMNAVSURFPAC  evaluators,  representing  over  7  0  years  of  SUADPS 
experience.   Enclosures  (1)  through  (3)  are  a  consolidated  input,  based 
on  the  evaluators'  review. 

2.  In  general,  the  evaluators  found  this  functional  assessment  process 
to  be  difficult,  at  best.   Also,  the  evaluators  found  that  a  significant 
number  of  applications  which  are  identified  as  currently  being  available 
in  SUADPS  are,  in  fact,  not  available.  The  reverse  situation  was  also 
found  to  exist.   The  fact  that  our  evaluators  could  not  reach  the  same 
conclusion  as  NAVMASSO  as  to  whether  or  not  an  application  is  available 
in  SUADPS,  supports  our  finding  that  it  is  difficult  to  interpret  the 
meaning  of  the  functions  and  applications.   In  short,  any  conclusions 
drawn  from  this  study  must  be  viewed  with  caution.   The  following 

c  omment  s  app ly : 

a.  Numerous  business  functions  and/or  applications  could  not  be 
interpreted  as  to  their  actual  meaning; 

b.  Functions  and  applications  as  stated,  often  duplicated  or 
overlapped  other  applications;  and 

c.  Many  of  the  business  applications  "considered  necessary"  for  modern 
afloat  supply  operations  are  defined  in  terms  of  current  SUADPS  terminology 
and  are  questionable  "required"  applications.   (Example:  Validation  Tables, 
Local  Constants,  Counters.)  These  applications  are  required  in  our  current 
system  design,  but  may  be  unnecessary  in  a  redesigned  system  with  different 
goals  and  objectives. 

3.  Interestingly,  the  evaluation  shows  that  individually,  many  of  the 
SUADPS  applications  work  as  advertised.   But  as  evidenced  from  our 
operational  experience,  there  are  numerous  problems  when  these  inter-related 
applications  are  combined.   There  is  no  synergy  in  the  current  process. 
This  is  due  in  part  to  the  complexity  of  Navy  Stock  Fund  financial  reporting 
requirements  and  the  computer  programming  required  in  SUADPS  to  support  this 
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effort.   This,  coupled  with  the  level  of  knowledge  required  to  understand 
and  manage  this  system  are  the  root  of  our  problems.  We  must  simplify, 
simplify,  simplify! 

As  stated  numerous  times  in  the  past,  to  simplify  the  process  we  must 
use  today's  technology  and  link  afloat  data  bases  with  shore-based  systems 
to  utilize  the  synergistic  effect  of  shared  information.  No  one  is  debatin 
the  fact  that  there  are  obviously  good  ideas  in  SUADPS,  OMMS,  IMMS/MRMS,  an 
SNAP  II  SFM/MDS,  along  with  other  shipboard  AIS's.  But,  as  agreed  upon  at 
the  January  1987  MMAIP,  a  zero  based  redesign  is  the  only  way  we  can  get 
away  from  making  an  overly  complex  system  even  more  complex  by  applying 
bandaids  to  continually  correct  system  deficiencies.  Acknowledging  that  we 
have  already  embarked  on  one  grandiose  zero  based  redesign  effort  which 
failed  because  of  it's  own  weight  and  that  the  chance  of  starting  another 
zero  based  redesign  to  achieve  an  optimal  solution  is  unlikely,  than  we  hav 
to  do  something  to  help  people  better  understand  the  system  in  place.  To  d 
this,  we  ought  to  capitalize  on  the  effort  that  has  already  gone  into  the 
zero  based  redesign  and  list  the  information  that  people  have  already 
identified  as  being  the  information  they  want  to  derive.  Then  a  matrix  cap 
be  constructed  showing  the  desired  information  product  on  the  left  and  the 
existing  business  functions  on  the  right  which  can  be  utilized  to  provide 
the  desired  information.  Business  functions  that  do  not  contribute  to  a 
specific  desired  information  product  should  be  candidates  for  elimination. 
The  resulting  business  functions  can  then  be  evaluated  to  see  if  they  can  1 
simplified  or  if  the  burden  of  using  them  exceeds  the  value  of  the 
information  derived.  In  this  way,  the  business  functions  can  be  evaluated 
in  context  of  the  role  they  play  in  the  overall  system.  To  try  to  evaluate 
the  business  functions  as  stand  alone  entities  is  confusing  to  all  concerne 
and  can  lead  to  a  lack  of  coordination  and  agreement  on  how  to  interpret  th 
questions  and  therefore  to  a  data  base  of  answers  which  may  be  seriously 
misinterpreted. 

5.   COMNAVSURFPAC  point  of  contact  is  CDR  C.  A.  Toledo,  SC,  USN,  Code  713, 
or  CAPT  G.  Locke,  USMC,  Code  713A  at  AUTOVON  526-5748  or  commercial  (619) 
556-5748. 


K.  W.  LIBBY 
By  direction 
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UNITED  STATES  MARINE  CORPS 
2d  MARINE  AIRCRAFT  WING,  FMF ,  ATLANTIC 

MARINE  CORPS  AIR  STATION 
CHERRY  POINT,  NORTH  CAROLINA  28533-6001 

IN  REPLY  REFER 
TO 

4400 

ALD/srf 

15  Jul  1991 

From:   Commanding  General,  Second  Marine  Aircraft  Wing 
To:     Command-,  Naval  Supply  System  Command  (0332), 
Washington,  DC  20376-5000 

Subj  :    SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT  RESPONSE 

Ref :    Commander,  Naval  Supply  Systems  Command,  0332  over  4400 
dated  24  May  1551 

End:   (1)    Type  Commander   SUADPS   Functional  Evaluation 

(2)  Type  Commander  SUADPS  Functional  Needs  Assessment 

(3)  Type  Commander  SUADPS  Reports  Critique 

1.  As  requested,  the  enclosures  have  been  reviewed  and  annotated. 

2.  Please  note  that  this  package  was  reviewed  from  a  Marine  aviation 
logistics  perspective  which  includes  both  NALCOMIS  and  SUADPS-RT 
processing  systems.   The  on-line  help  function  in  NALCOMIS  is  a  very 
valuable  tool.   This  function  does  not  exist  in  SUADPS-RT  but  should  be 
implemented  in  any  follow-on  system. 

3.  2d  MAW  POC:  CWO-2  S.   Foster,  ALD-L,  Av:  582-5111/3933. 


M.  C.  SKIPPER 
By  direction 

Copy  to: 
CMC  (ASL-32) 
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DEPARTMENT    OF    THE   NAVY 
COMMANDER   NAVA1    AIR    FORCE 

UNITED   STATES    PACIFIC    FLEET 
NAVAL   AIR    STATION,    NORTH    ISLAND 
SAN    DIEGO,    CALIFORNIA    92135-5100 


4400 

Ser  453/6561 

06  AUG  1991 

From:    Commander  Naval  Air  Force,  U.S.  Pacific  Fleet 
To:      Commander,  Naval  Supply  Systems  Command 

Subj  :    SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT 

Ref:     (a)  COMNAVSUPSYSCOM  ltr  0332  4400  of  24  May  91 

Encl:    (1)  Type  Commander  SUADPS  Functional  Evaluation 

(2)  Type  Commander  SUADPS  Functional  Needs  Assessment 

(3)  Type  Commander  SUADPS  Reports  Critique 

1.  The  SUADPS  products  forwarded  by  reference  (a)  have  been  reviewed 
and  are  being  returned  as  enclosures  (I)  through  (3).  The  following 

c  ommen t s  app ly : 

a.  Many  of  the  business  functions  and/or  applications  were  not 
understood  by  anyone  on  this  staff;  the  package  was  reviewed  by  two 
Senior  and  two  Master  Chief  Petty  Officers,  a  GS-12  Financial  Analyst,  a 
Lieutenant  (former  stock  control  officer)  and  two  former  SUADPS 
experienced  Limited  Duty  Officers,  one  was  a  Lieutenant  Commander  with 
31  years  experience  and  the  second  was  a  Lieutenant  with  27  years 
experience.  The  difficulty  of  developing  a  comprehensive  and  explicit 
functional  evaluation  for  a  baseline  review  of  our  current  business 
applications  is  appreciated,  however  the  one  or  two  word  descriptions 
provided  for  the  function,  sub-function  and  application  titles  were  much 
too  general  in  nature  resulting  in  a  lot  of  confusion  about  what 
function  actually  was  being  analyzed. 

b.  Functions  and  applications  were  frequently  either  duplicated  or 
contained  within  other  applications. 

c.  Many  of  the  applications  do  not  appear  to  be  related  to  SUADPS 
Release  3  or  any  other  management  system  of  the  future  which  will  replace 
Release  3  (e.g.  SAMS,  ADMIN  and  Ship's  Store  Returns).   The  fact  that  thes 
applications  are  performed  aboard  ships  does  not  make  them  viable  candidats 
for  inclusion  in  a  mainframe  computer  Supply  and  Financial  Management  Systl 
of  the  future  cannot  and  should  not  be  an  all  inclusive  AIS  containing  eve( 
conceivable  function  performed  aboard  ships.  Not  only  should  some  of  those 
functions  be  properly  accomplished  manually,  but  also  those  functions  thatH 
stand  alone  and  can  be  performed  on  a  micro-computer  system  should  remain  i 
micro  computers . 

2.  The  objective  of  any  future  inventory/financial  management  system  shoi 
be  to  enable  the  shipboard  storekeeper  to  concentrate  his  efforts  on  accur 
receipt,  issue  and  inventory 
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control  procedures  and  not  have  to  worry  whether  the  appropriation  data  for 
another  ship  he  has  just  made  a  transfer  to  is  contained  in  validation  tables. 
Those  financial  applications  can  and  should  be  performed  ashore  with  existing 
technology  used  to  communicate  to  the  shore  facility  what  material 
transactions  have  occurred. 

3.  The  tremendous  effort  put  into  developing  this  baseline  review  is  obvious; 
the  validity  of  the  results  are  certain  to  be  suspect  given  the  ambiguities  of 
the  functional  descriptions.  Informal  conversations  with  COMNAVSURFPAC  and 
COMNAVAIRLANT  have  expressed  the  same  concern  and  frustration  of  attempting  to 
design  software  by  mail.  A  working  level  (one  or  two  experts  per  TYCOM  and 
CDA)  conference  to  review  the  results  and  clear  up  any  lingering  concerns  to 
be  the  next  step  in  this  process. 

4.  COMNAVAIRPAC  point  of  contact  is  CDR  R.  A.  Boyd,  Code  45  or  LT 

E.  S.  Walters,  Code  453  at  AUTOVON  735-1020  or  Commercial  (619)  545-1020. 


R.  A.  BOYD 
By  direction 
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DEPARTMENT    OF    THE   NAVY 

COMMANDER    SUBMARINE    FORCE 

U.S,     ATLANTIC    FLEET 

NORFOLK,    VIRGINIA    23511-5230 

4400 

Ser  N531/2153 
16  AUG  1991 

From:    Commander  Submarine  Force,  U.S.  Atlantic  Fleet  Commander, 
To:      Commander,  Naval  Supply  Systems  Command  (SUP  03  3) 

Subj  :     SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT 

Ref:      (a)  NAVSUP  ltr  Ser  0332/4400  of  24  May  91 

Encl:     (1)  Type  Commander  SUADPS  Functional  Evaluation 

(2)  Type  Commander  SUADPS  Functional  Needs  Assessment 

(3)  Type  Commander  SUADPS  Reports  Critique 

1.  As  requested  by  reference  (a),  enclosures  (1)  through  (3)  are 
forwarded. 

2.  Request  COMSUBLANT  be  provided  with  summary  results  of  the  Type 
Commanders  SUADPS  Functional  Assessment  no  later  than  30  September  1991. 


T.  O.  DUFFEY 
By  direction 
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DEPARTMENT    OF    THE   NAVY 

COMMANDER    SUBMARINE    FORCE 
UNITED   STATES    PACIFIC    FLEET 
PEARL   HARBOR,    HI    96860-6550 

4400 

Ser  5113/004436 
27  JUN  1991 

From:    Commander  Submarine  Force,  U.S.  Pacific  Fleet 
To:      Commander,  Naval  Supply  Systems  Command 

Subj  :    SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT 

Ref:      (a)  COMNAVSUPSYSCOM  ltr  Ser  0332-4400  of  24  May  91 

End:     (1)  Applications  Found  in  Various  Afloat  Business  Systems 

Questionnaires  and  Type  Commander  SUADPS  Functional  Evaluations 

1.  The  functional  assessment  enclosed  in  reference  (a)  has  been 
reviewed  and  is  returned  as  enclosure  (1). 

2.  COMSUBPAC  point  of  contact  is  LT  Jim  Barnard  (Code  5113),  who  may 
be  reached  at  A/V  471-8111  or  COML  (808)  471-0464/474-5538. 


D.  R.  LENGKEEK 
By  direction 
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Ref  : 

(a) 

End: 

(I) 

(2) 

(3) 

(4) 

DEPARTMENT    OF    THE   NAVY 

COMMANDER  NAVAL  SURFACE  FORCE 
UNITED  STATES  ATLANTIC  FLEET 
NORFOLK,    VIRGINIA   23511-5215 

4400 

Ser  N72/09579 
8  AUG  1991 

From:    Commander,  Naval  Surface  Force,  U.S.  Atlantic  Fleet 
To:      Commander,  Naval  Supply  Systems  Command  (Code  0332) 

Subj  :    SUADPS-RT  REL  3.0  FUNCTIONAL  ASSESSMENT 

COMNAVSUPSYSCOM  0332  4400  of  24  May  91 

Response  Matrix 

SUADPS  Functional  Evaluation  Work  Sheets 
SUADPS  Functional  Needs  Assessment  Work  Sheets 
SUADPS  Reports  Critique 

1.  As  requested  by  reference  (a),  enclosures  (1)  through  (4)  are 
forwarded  as  input  to  the, ' comprehensive  evaluation  of  SUADPS. 

2.  The  Response  Matrix,  enclosure  (1),  is  provided  as  a  summary  sheet 
of  responses  to  key  questions  as  viewed  from  the  TYCOM'S  perspective. 
Note  that  the  column  addressed  as:  (1)  Non-applicable  (N/A)  contains 
responses  to  functionality  not  intended  for  SUADPS  processing  and  (2) 
Insufficient  Information  contains  responses  to  functionality  that  lacked 
sufficient  descriptive  information  to  clearly  determine  its  intended 
purpose  or  processing  goals. 

3.  My  point  of  contact  for  further  information  is  LT  D.  Lendle  (N723), 
AUTOVON  564-5882  or  commercial  (804)  444-5882.   FAX  number  is  (804)  445- 
2236. 


J.  E.  COOK 
By  direction 
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ENCLOSURE  ( 1 ) 

CNSL  RESPONSE  MATRIX 


1)   TYCOM  FUNCTIONAL  EVALUATION; 


QUESTION 


IA 

2 

8 


2      3      4    N/A  INSUFFICENT 

NO YES  INFORMATION 

2    0       1     61  13         14 

2    7      5     48  15         14 

61   0      0     1  15         14 


(2)  TYCOM  FUNCTIONAL  NEEDS 


QUESTION 


l.A 
4 


1 

2 

3 

4 

Mn 

YES 

1MU 
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0 

0 

5 

1 

3 

N/A  INSUFFICENT 
INFORMATION 
15    3  II 

7   75  12 


ENCL  ( I 
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